인터넷 연결을 끊으세요

 (computer.rip)
1P by GN⁺ | ★ favorite | 댓글 1개
  • CrowdStrike 사고 같은 대형 보안 사건 뒤에는 “인터넷에 연결하지 말았어야 한다”는 반응이 나오지만, 많은 업무 시스템은 정보 교환이 핵심 기능이라 단순 차단으로 해결되지 않음
  • 항공 예약·스케줄링 시스템처럼 조직과 지역 경계를 넘는 시스템은 전화와 전신을 대체한 통신 인프라에 가까워, 네트워킹을 제거하면 본래 가치도 함께 사라짐
  • “인터넷에 연결되지 않음”은 단일 장비, 엄격한 에어갭, 데이터 다이오드, 사설 WAN, VPN 터널, 제한적 라우팅, AWS private VPC까지 포함할 수 있어 위협 모델이 크게 달라짐
  • 오프라인 또는 제한 연결 환경에서는 OS 업데이트, 패키지 관리자, 내부 저장소, TLS 신뢰 저장소, 클라우드 라이선스, 콘텐츠 업데이트, Docker 이미지 처리까지 모두 시간과 비용을 밀어 올림
  • 더 많은 시스템에 제한적 네트워크 정책을 적용하고 오프라인 운영을 고려해 소프트웨어를 만들 수는 있지만, 현재 소프트웨어 생태계는 여전히 인터넷 연결을 기본값으로 삼고 있음

“인터넷에 연결하지 말라”는 말의 한계

  • 대형 보안 사고가 뉴스가 될 때마다 “이런 시스템은 인터넷에 연결되어 있으면 안 된다”는 반응이 반복됨
  • 이 판단은 보안과 안정성 측면에서 직관적 매력이 있지만, 실제로 그렇게 운영되는 환경은 많지 않음
  • 핵심 문제는 “인터넷에 연결하지 않는다”는 말만으로는 실제 설계, 운영 비용, 위협 모델을 충분히 특정할 수 없다는 점임

현대 업무 시스템은 통신 장치에 가까움

  • 추상적으로 컴퓨터는 계산을 통해 가치를 만들 수 있지만, 산업 현장의 시스템은 계산보다 정보기술의 성격이 강함
  • 정보기술은 정보를 입력받고 출력해야 하며, 과거처럼 운영자가 테이프를 넣는 방식은 실시간 통신보다 비싸고 느림
  • 현대 업무용 컴퓨터는 대부분 통신 장치로 기능함
  • 다른 업무 시스템과 연결되지 않고 가치를 만드는 시스템은 많지 않음
    • 이런 연결은 조직 경계와 지리적 경계를 넘는 경우가 많음
    • 항공 예약·스케줄링 시스템은 전화와 전신을 대체한 시스템에서 출발했으며, 네트워크가 기능 자체에 포함됨

유지보수와 운영에도 네트워크가 필요함

  • 실시간 통신이 업무 목적에 필수적이지 않은 시스템도 네트워크 연결이 운영상 큰 가치를 가짐
  • 인터넷 연결이 없으면 소프트웨어 업데이트를 어떻게 가져올지, 시스템을 어떻게 모니터링할지부터 막힘
  • 시스템이 “완성”되어 업데이트나 실시간 모니터링이 필요 없다고 정해도, 비즈니스 요구사항은 시간이 지나며 바뀜
  • 네트워크 연결은 이런 변경을 처리하는 비용을 크게 낮춤

“인터넷 미연결”에는 여러 수준이 있음

  • “인터넷에 연결되지 않았다”는 상태는 단일한 의미가 아니라 여러 구현 방식의 묶음임
  • 가능한 형태는 완전 단절부터 제한적 연결까지 넓게 분포함
    • 네트워크 연결이 전혀 없는 단일 장비
    • 사설 LAN 외에는 연결이 없고 보안 경계를 데이터가 넘지 않는 엄격한 에어갭
    • DVD-R로 데이터를 보안 경계 안으로 반입하는 에어갭
    • cross-domain solution 또는 data diode로 낮은 보안 네트워크에서 높은 보안 네트워크로 데이터를 이동하는 구조
    • NSA 인증이 없는 cross-domain solution을 쓰는 구조
  • 사설 광역망도 여러 단계로 나뉨
    • 완전히 독립된 물리 인프라와 변조 방지 조치를 갖춘 사설 WAN
    • 공유 덕트, leased dark fiber, lit fiber의 wavelength를 쓰는 형태
    • MPLS 기반 virtual private ethernet
    • 암호화와 인증을 갖춘 터널링 기반 virtual private ethernet
  • 공용 통신망 위의 사설 트래픽도 “미연결”으로 불리는 경우가 있음
    • 인터넷 같은 common-carrier network 위에서 하드웨어 장비가 암호화·인증 터널을 구성하는 형태
    • NSA 인증이 없는 장비를 쓰는 형태
    • 운영체제 네트워크 스택을 낮은 수준에서 설정해 터널 우회를 막는 검증된 소프트웨어 터널
    • 검증 수준이 낮은 소프트웨어 터널
    • WireGuard와 iptables 스크립트를 조합한 형태
  • 제한적 인터넷 연결도 같은 말로 묶임
    • 정책 기반 라우팅 등으로 극히 좁은 트래픽 흐름만 허용하는 사설 네트워크
    • 허용 흐름이 오래된 Jira 티켓에 남아 있고 일부는 “동작하게 하려고” 추가된 구조
    • 아웃바운드는 비교적 관대하고 인바운드는 엄격한 방화벽 기반 구조
  • 클라우드 환경에서도 범위가 흔들림
    • 외부 라우팅이 없는 AWS private VPC
    • PrivateLink 등으로 다른 private VPC와 통신하는 VPC
    • 연결된 일부 VPC가 인터넷과 라우팅되는 구조
    • NAT Gateway와 Internet Gateway가 있지만 security group을 양방향으로 엄격히 설정한 구조
  • 이런 형태들은 모두 “인터넷에 연결되지 않음”으로 불린 사례가 있지만, 공격 표면과 위험은 각각 다름
  • 항공 예약 시스템을 “인터넷에 연결하지 말라”고 할 때 완전 무네트워크 상태를 뜻하지 않는다면, 실제로는 중간 단계 중 하나를 뜻하며 각 단계마다 실무 고려사항이 달라짐

오프라인 환경은 비용과 일정을 크게 늘림

  • 인터넷 연결이 없거나 강하게 제한된 네트워크에서 소프트웨어를 운영하면 일정과 비용 추정이 크게 늘어남
    • AWS private VPC 같은 약한 형태는 대략 3~5배로 잡을 수 있음
    • 완전 단절에 가까운 강한 형태는 10배에서 훨씬 더 커질 수 있음
  • 거의 전체 소프트웨어 생태계가 인터넷 연결을 전제로 설계되어 있음
    • 운영체제는 온라인 서버에서 업데이트를 가져오려 함
    • 유료 OS 벤더는 사설망 내부 업데이트 인프라를 별도 유료 라이선스로 제공할 수 있음
    • 무료 OS는 직접 해결할 수 있지만 최신 기술을 쓰면 큰 번거로움이 생길 수 있음
  • 개발과 배포 과정에서는 여러 패키지 관리자와 내부 저장소 문제가 반복됨
    • 패키지 관리자마다 사설 내부 저장소 지원 수준이 다름
    • 여러 패키지 관리자, 호출 방식, 실행 환경이 조합되며 복잡도가 커짐
  • 내부 서비스의 TLS 인증서도 반복적인 작업을 만듦
    • 사설망 내부 서비스는 대중적 CA의 루트 프로그램에 포함된 인증서를 쓰지 않는 경우가 많음
    • JRE처럼 별도 trust store를 가진 구성 요소가 있고, 일부 기술 스택에서는 라이브러리에 따라 동작이 달라짐
    • 운영체제 trust store가 있어도 각 도구가 자체 저장소를 쓰면 별도 조정이 필요함
  • 클라우드 라이선스와 entitlement 확인도 장애물이 됨
    • 일부 소프트웨어는 클라우드 라이선스 확인을 위해 외부에 접속하려 함
    • 우회 방법은 대규모 방화벽 예외 추가부터 맞춤형 라이선스 체계 발급까지 다양하고 시간이 걸릴 수 있음
  • 오프라인 콘텐츠 업데이트는 벤더 프로세스만으로도 복잡해질 수 있음
    • 한 엔터프라이즈 소프트웨어 사례에서는 오래된 고객 지원 포털과 별도 entitlement 포털을 거쳐야 했음
    • 계정 개설과 에스컬레이션에 3개월 이상이 걸렸고, 최종 포털에는 유효하지 않은 TLS 인증서가 있었음
    • 문서화된 업데이트 적용 절차가 더 이상 동작하지 않아 엔지니어와 긴 이메일 교환이 필요했음
    • 1년 라이선스에 5자리 금액을 지불했지만 사용 준비 과정에서 거의 만료됐고, 연장 라이선스 발급 지연으로 CI 파이프라인 중단이 발생함
  • 오프라인 운영의 어려움은 개별 작업 하나가 불가능해서가 아니라, 모든 작업이 조금씩 더 어려워지는 death by a thousand cuts에 가까움
  • 오프라인 환경을 고려하지 않은 제품은 임시 스크립트와 땜질로 대응하는 경우가 많고, 그 기술 부채는 오프라인 환경을 운영하는 고객에게 넘어감
  • Red Hat은 이 영역에 비교적 잘 대응하지만, 절약한 시간만큼 비용을 현금으로 지불하게 됨

이런 환경은 드물고 특정 산업에 집중됨

  • 강한 형태의 비인터넷 연결 환경은 주로 국방·정보기관에서 보임
  • 일부 은행도 강한 네트워크 분리 관행을 갖고 있음
  • 국방, 정보기관, 은행은 비용이 높고 시간이 오래 걸리는 산업으로도 알려져 있으며, 이런 운영 방식과 무관하지 않음
  • 약한 형태의 제한 연결 환경은 주로 금융과 의료 같은 고규제 산업에 많음
  • 보안을 매우 중시해 네트워크를 강하게 잠그는 일반 소프트웨어 회사도 가끔 있음

지금 할 수 있는 실용적 대응

  • 더 적은 시스템이 인터넷에 연결되는 방향 자체가 나쁜 생각은 아님
  • 다만 현재 소프트웨어 산업은 인터넷이 없거나 제한된 환경에서 편하게 운영되도록 준비되어 있지 않음
  • 현실적인 대응은 완전 단절을 외치는 것보다 제한적 연결과 오프라인 대응성을 늘리는 쪽에 가까움

  • 네트워크 정책을 최대한 제한하기

    • 가능한 많은 시스템에 제한적 네트워크 정책을 적용해야 함
    • 클라우드 제공자는 과거보다 이런 구성을 쉽게 만들고 있음
    • AWS에서는 실용적인 비인터넷 라우팅 환경을 운영하는 것이 아주 쉽지는 않지만 불가능할 만큼 어렵지도 않음
    • AWS managed service 범위 안에 머무르면 대체로 고통이 적지만, 비용은 발생함

  • 오프라인 환경을 고려해 소프트웨어 만들기

    • 외부로 접속해야 하는 기능은 가능하면 비활성화할 수 있어야 함
    • 비활성화가 어렵다면 사용할 endpoint를 고객이 바꿀 수 있어야 함
    • endpoint를 바꿀 수 있게 한다면 고객이 자체 endpoint를 운영할 수 있는 방법도 필요함
    • 단순 정적 파일이면 nginx와 디렉터리 정도로 쉽게 제공 가능함
    • API라면 내부 구현을 고객에게 배포해야 할 수 있고 유지보수 부담이 생김

  • TLS와 의존성 가정 줄이기

    • 오프라인 환경에서는 다른 서비스에 연결한다는 작은 가정들이 복잡해짐
    • Let’s Encrypt에 접속할 수 있다고 가정하면 안 됨
    • 오프라인 환경은 거의 항상 내부 인증기관을 수반함
    • system trust store를 사용해야 함
    • 배포 시점에 요구사항이나 의존성을 가져오지 않아야 함
    • Docker는 패키지를 자기완결적으로 만들겠다는 장점이 있었지만, npm 저장소 등에 접속하지 못하면 시작하지 못하는 컨테이너도 있음
    • Docker 컨테이너마다 TLS trust store를 수정해야 하는 경우가 있어, 오프라인 환경에서는 Docker가 오히려 관리를 더 어렵게 만들 수 있음

CrowdStrike 사고와 인터넷 연결의 관계

  • CrowdStrike 사고에 대해 “왜 인터넷에 연결되어 있었나”라는 반응이 여러 번 나왔지만, 인터넷 연결 여부는 당시 발생한 문제와 거의 직교함
  • CrowdStrike 콘텐츠 업데이트는 이상적인 환경이라면 오프라인 환경에도 신속히 제공되어야 하는 종류의 업데이트임
  • 실제 강한 오프라인 환경에서는 내부 CrowdStrike 업데이트 미러가 며칠, 몇 주, 몇 달, 몇 년씩 뒤처질 수 있음
  • 그런 지연이 문제를 피하게 만들 수는 있지만, 이는 두 가지 잘못이 겹쳐 우연히 맞아떨어지는 상황에 가까움

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 보안/시스템/운영 쪽에서 일하지만, 이 전제에는 근본적으로 동의하지 않음. 글쓴이가 “그렇게 쉽지 않다”고 말하는 건 이해하고 전적으로 동의하지만, 그렇다고 그게 일을 잘하고 있다는 뜻은 아님
    안타깝게도 대부분은 일을 잘 못하고, 업계 전체가 일을 못해도 버틸 수 있게 해주면서 일을 잘하기는 어렵게 설계돼 있음
    디지털 사이니지를 배포한다면 네트워크 접근은 내 서버 IP 주소로만 허용 목록 처리돼야 하고, 서명된 업데이트와 인증서 고정(certificate pinning)으로 맺어진 연결만 받아야 함
    이렇게 하면 원격 공격자가 건드리기 거의 불가능해짐. 사물인터넷(IoT) 확산으로 커진 보안 산업을 보면, 열린 포트와 기본 비밀번호가 남아 있는 사이니지나 다른 IoT/SCADA/배포 장비가 분명히 있음
    IoT는 그냥 컴퓨터지만, 이미 제대로 운영 못 하는 서버나 가상 머신보다 더 방치되는 컴퓨터이기도 함
    잘하는 곳도 있지만 극소수이고, 잘하라고 보상받는 구조가 아니기 때문임. “모범 사례”나 벤더 지침을 따르는 건 잘한다는 뜻이 아니라, 벤더가 지원해줄 만큼만 했다는 뜻일 때가 많고, 많은 경우엔 제한 없는 네트워크 접근을 의미함

    • 인터넷에 연결된 사이니지가 IP 허용 목록과 암호학적 검사를 갖췄더라도 여전히 인터넷에 연결된 것임. 전 세계에 포트가 열려 있고 인증도 없는 것보다는 훨씬 안전하지만, “인터넷에 연결되지 않았다”고 취급할 수는 없음
      네트워크 버그, 암호 취약점, 설정 오류, 그 밖에 원격 공격자가 시스템을 악용할 수 있는 문제를 여전히 걱정해야 함. 이 주장을 하려면 단순히 더 잠근 사례가 아니라, 말 그대로 인터넷에 연결되지 않은 예를 들어야 함
    • IoT에서는 특히 임베디드 개발자들이 고급 보안 개념을 많이 다뤄보지 않은 지점에서 갈림길에 서게 되고, 결국 구현을 꽤 세밀하게 관리해야 함. 작은 팀에서는 x509 인증서와 그에 딸린 절차를 관리하는 부담을 정당화하기도 어렵다는 게 개인적인 경험임
    • 이 말이 정확히 무슨 뜻인지 더 설명해줄 수 있음? 보기에는 오히려 시스템이 인터넷과 어떻게 통신하는지 더 명확히 생각해야 하는 또 다른 문제 묶음을 강조하는 것처럼 보임
      블로그 글쓴이와 어디서 의견이 갈리는지 잘 모르겠음. 아니면 사람들이 그럴 역량이 없기 때문에 인터넷 연결 시스템의 보안을 개선하는 게 근본적으로 불가능하다는 뜻인가?
    • 이런 엣지 장비에 제대로 된 보안 표준을 넣도록 벤더를 강제하는, 실제로 강제력 있는 법안도 일부 시행되고 있음: https://www.withersworldwide.com/en-gb/insight/read/new-uk-l...

  • 스웨덴에는 인터넷과 분리된 사설망 Sjunet이 있고, 의료 제공자들이 사용함. 목적은 컴퓨터를 가치 있는 통신 장치로 만들되, 병원 IT를 전체 인터넷에 노출하지 않는 것임
    Sjunet 회원들은 자기 네트워크를 알고 IT를 엄격히 통제해야 한다고 기대됨
    Sjunet은 업계 단위의 에어갭 환경으로 볼 수도 있음. 보안을 개선하면서도, 각 조직이 거대한 허용 목록을 가진 자체 에어갭 네트워크를 운영하는 것보다는 비용이 작다고 봄

    • 그게 병원 IT에 가짜 안도감을 줄 것 같음. 거대한 인트라넷은 현대적 모범 사례와는 거의 반대에 가까움: https://en.wikipedia.org/wiki/Zero_trust_security_model
    • 영국에도 HSCN이라는 게 있음. 좋은 것 같지는 않음. 몇 년 전만 해도 “승인된” 인증서 제공자가 몇 곳뿐이라 TLS 인증서 하나에 수백 달러를 내야 했음
      가짜 안도감을 주고 나쁜 보안 정책의 핑계도 됨. 대역폭은 낮고 비쌈
    • 폴란드에는 잘 알려지지 않은 “źródło”(영어로 “source”라는 뜻)가 있음
      군청, 시청 같은 기관들을 연결해 시민 개인정보가 저장된 중앙 데이터베이스에 접근하게 해주는 네트워크임. 주소 변경, 새 신분증 발급, 출생·혼인 등록 같은 일을 할 때 쓰임
      아는 한 “Źródło” 앱은 별도의 “에어갭” 컴퓨터에서 실행되고, 인터넷은 안 되지만 내부망에는 접근하며, 스마트카드를 통한 암호학적 클라이언트 인증서로 인증함
    • 거의 모든 다른 나라의 의료 IT 상태를 보면, “Sjunet 회원들은 자기 네트워크를 알고 IT를 엄격히 통제해야 한다”는 말에 실제 의미가 있다고 믿을 이유가 있나? 정부가 네트워크의 모든 컴퓨터를 감사하나?
      모두 최신 패치가 적용돼 있나? 사람들이 아무 USB 장치나 꽂지 않는다는 걸 알고 있나?
    • 90년대 인터넷 같았던 광역망이 있으면 좋겠음. 취미적인 요소가 더 많고, 상업적인 건 없고, 규제도 없는 식으로
      Tor와 비슷하지만 수상한 것들은 없는 느낌이면 좋겠음

  • 제어 엔지니어로 수백 대의 기계를 만들었음. 현장버스 네트워크용 이더넷 케이블은 있지만, 절대 인터넷에 연결되면 안 됨
    동네 산업단지의 공구·금형 작업장마다 인터넷에 올려서는 안 되는 이더넷 포트 달린 CNC 기계가 있음. 맞춤 장비, 컨베이어 라인, 프레스, 로봇, CNC, 펌프 스테이션 등이 있는 모든 제조 공장은 이더넷을 쓰지만 인터넷 노출에 적합하지 않은 PLC와 HMI 시스템을 사용함
    글은 현대 업무용 컴퓨터가 거의 주로 통신 장치이며, 다른 업무 시스템과 연결되지 않고 가치를 만드는 실무 시스템은 많지 않다고 말하지만, 제조업 전체와 그 제조업이 만드는 전자 장치를 무시하고 있음
    수백만 개의 임베디드 시스템과 PLC는 매 1밀리초마다 물리·논리 디지털 입력 상태가 바뀌었는지 확인하고, 바뀌었다면 물리·논리 디지털 출력 상태를 바꾸면서 하루 종일 가치를 만듦
    주물이 100년도 전에 만들어졌고, 마지막 업데이트가 2003년에 레시피 설정용 PLC와 흑백 화면을 붙인 것이었던 저항 용접기에 2024년식 보안 시스템을 넣을 필요는 없음. 클립보드를 들고 가서 목표값을 입력하고 정확히 강철을 녹이면 됨
    보통 이런 기계에 연결하려면 노트북을 들고 이더넷 패치 케이블을 가지고 기계 앞까지 걸어가야 함. 그 이상이 필요하다면 고객에게 방화벽이 있는 운영기술(OT) 네트워크에 두거나, Tosibox, Ixon 같은 SCADA/VPN 장비로 정보기술(IT)과 OT 사이를 연결하라고 기대함

    • 그런 장비들이 아직 존재한다니 안심됨. 소비자용 하드웨어에 대한 내 머릿속 모델은, 당신이 설명한 장치에 Wi-Fi, Bluetooth, 원격측정, 광고, 앱을 그냥 추가한 것에 가까움
    • PLC는 국가의 중요 기반시설 대부분을 제어하고, 에어갭 네트워크 안의 고가치 종단점과도 연결되기 때문에 명시적으로 고가치 표적으로 간주됨
      당신이 다루는 게 누군가 악용하고 싶어 할 대상이 아닐 수도 있지만, PLC는 중요 기반시설과 고급 제조 시설에서 자주 발견되기 때문에 악의적 행위자에게 매력적인 표적임. 중요 기반시설을 악용하려 하거나, 언젠가 엔지니어링 노트북 같은 고가치 종단점이 직접 연결할 수 있는 보안이 허술한 장치를 감염시키려 할 수 있음
      https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
      https://claroty.com/team82/research/evil-plc-attack-using-a-...

  • 인터넷 중심 개발 관행을 쓸 수 없게 되니 시스템을 에어갭하면 안 된다는 주장에는 여전히 납득이 안 됨. 이 주장은 터무니없다고 봄
    이더넷 포트를 에폭시로 막아야 하는 시스템이라면, 애초에 인터넷 중심 개발 관행으로 프로그래밍해서는 안 됐음. MRI 기계가 부팅할 때 NPM에서 JS 의존성을 가져온다고? 바로 감옥감임. 비유가 아니라 실제로

    • 의료 장비가 그런 식으로 동작한다면, 그건 형사처벌을 받아야 할 특수한 형태의 직무상 위법행위가 맞음

  • McDonald’s 키오스크를 만지는 사람 영상을 본 뒤로, 여러 장소에서 보이는 장비로 같은 일을 해보기 시작했음
    한 푸드코트에는 Windows가 깔리고 인터넷에 완전히 접근 가능한 키오스크가 있었음. 누군가 악성코드를 내려받아 신용카드 데이터를 훔칠 수 있었음. 쓸 때마다 전원을 끄거나 화면에 메시지를 남겼고, 결국 키오스크 모드로 돌리기 시작함
    또 하나는 주차 키오스크였는데 전혀 강화돼 있지 않았음. 범죄자들이 아직 눈치채지 못한 듯함
    세 번째는 맥주 브랜드의 인터랙티브 디스플레이였음. 큰 피해를 만들 물건은 아니었지만, 메모장을 열어 “Drink water”라고 남겨두는 게 좋았음. 결국 꺼버렸고, 그것도 해결책이긴 함

    • 근처 주차 키오스크가 어떻게 구성돼 있는지는 모르지만, 한 번은 답답해서 버튼을 마구 눌렀더니 내가 산 적도 없는 티켓에 대해 환불을 해주기 시작한 걸 보면 정말 엉망으로 만든 듯함
      “무작위 행인에게 돈을 주지 말 것”은 요구사항 목록에서 꽤 높은 위치에 있어야 할 텐데, 현실은 그렇지 않았음
    • 브라우저로 포르노를 띄워두면 아주 빠르게 고쳐질 것임

  • 이 부분은 정말 공감됨. IntelliJ의 JRE 신뢰 저장소가 zscaler용 새 인증서를 써야 한다는 걸 이해하게 만들려고 했는데, 선택 가능한 JDK가 두세 개 있었고 각각의 신뢰 저장소에 새 인증서를 넣었는데도 여전히 동작하지 않았고 이유를 알 수 없었음

  • hamnet도 있음. 44Net IP 블록 위에서 일부는 인터넷 라우팅이 가능하고 일부는 그렇지 않음
    https://hamnetdb.net/map.cgi
    아마추어 무선 주파수 대역을 쓰기 때문에 흥미로운 제약이 있음. 상업적 사용은 완전히 금지됨
    그게 해당 주파수 대역의 사회적 계약이라서, 136kHz부터 241GHz까지 많은 대역에 싸게 접근할 수 있지만 돈을 벌 수는 없음

    • 다만 업링크를 얻기가 정말 어려움. 대도시에서도 그럼
      네덜란드와 독일에서만 꽤 널리 퍼져 있음: https://hamnetdb.net/map.cgi . 여기 스페인에서는 내 근처 어디에서도 쓸 수 없음

  • 항공사 예약 시스템이 적어도 네트워크에는 연결돼야 한다는 건 꽤 명백해 보이고, 전부 오프라인이어야 한다고 주장하는 사람은 별로 못 들어봤음. 하지만 예를 들어 작업장의 선반 기계가 이번 일로 멈췄다는 얘기도 들었음
    정말 온라인이어야 했는지는 생각해봐야 함. 물론 이유는 있겠지만, 그 이유는 위험과 비교해 따져봐야 함
    그 밖에도 냉장고, 주전자, 차고 문처럼 인터넷에 연결된 더 우스운 예가 많음. 이런 것들이 CrowdStrike 사고에 영향을 받았는지는 모르지만, 아니었다 해도 다음번엔 시간문제일 뿐임
    연결되지 않은 시스템이 “매우, 매우 짜증난다”는 주장에 대해서는, 사용자로서의 경험상 모든 보안이 “매우, 매우 짜증남”. 2단계 인증, 의무 비밀번호 변경, 잠긴 장치, 악성코드 스캐너, 링크 정화기까지 일부는 필요하고 일부는 헛소리겠지만, 뭐가 뭔지 구분할 자격은 없고, 전부 마찰을 만든다는 건 확실함

    • 물론 네트워크는 필요함. 하지만 인터넷은 아님

  • 내가 얻은 큰 결론은 “이 모든 시스템이 인터넷에 연결되면 안 된다”가 아니라 다른 몇 가지임
    첫째, 이런 시스템은 아웃바운드 네트워크 흐름을 허용하면 안 됨. 그러면 모든 자동 업데이트가 막히고, 이후 내부 배포 채널로 관리할 수 있음
    둘째, 그렇게 하지 않더라도 많은 기업용 소프트웨어 제품에서는 자동 업데이트를 끌 수 있음. Windows가 대표적이고 CrowdStrike 자체도 마찬가지임. CS 고객 중 자동 업데이트를 끄고 수동 배포를 해서 피해를 피한 곳이 있었다고 들음
    셋째, 2번에 덧붙여 약간의 스모크 테스트를 거친 업데이트를 점진적으로 배포해야 함. 혹시 모르니까. 역시 CS 고객 중 점진 배포를 해서 일부 장비만 영향을 받게 막은 곳이 있었다고 들음

  • 군 고객에게 최첨단 AI 솔루션을 납품하던 시절을 꽤 잘 요약한 글임. 노력의 80%는 인터넷 전제 도구들을 에어갭 환경에서 매끄럽게 돌아가게 만드는 데 들어갔음

답변달기