데이터를 시스템에서 분리: 설계로 완성하는 불변성

대부분 조직은 서버가 귀한 것인 양 보호합니다. 이미지 만들고, 백업하고, 불안하게 패치하고, 하나 죽거나 침해되면 원래 모습 그대로 복원하느라 시간을 쏟습니다. 정작 데이터, 진짜 가치 있는 부분은 그 같은 서버 위에 살면서 서버가 우연히 받은 수준의 보호만 받습니다.

그 관계를 뒤집으면 많은 보안이 단순해집니다. 시스템은 버리고, 데이터는 보석으로 다루세요. 서버를 코드로 만들어 며칠 복원 대신 몇 분 교체가 되게 하세요. 그다음 진짜 보호 노력을 있어야 할 곳에 집중하세요. 바로 데이터 자체, 생애 전반을 추적받고, 의도적으로 백업되고, 점점 더 처리하는 시스템이 아닌 어딘가에 사는 것입니다.

수리하지 말고 재배포하는 시스템 #

오래된 모델은 서버를 애완동물처럼 취급했습니다. 각각 이름, 성격, 아무도 완전히 기록 못 한 수동 수정 역사가 있습니다. 펫-서버가 죽으면 복구는 고고학입니다. 기억과 메모와 희망으로 몇 년치 변경을 재건하는 것이죠.

현대 모델은 DevOps 문구 중 트렌드보다 오래 산 cattle(가축)로 서버를 다룹니다. 병든 동물을 되살리지 않습니다. 교체하고 계속합니다. 실제로 이것을 의미합니다:

Infrastructure as code. 모든 서버, 컨테이너, 구성이 선언적으로 정의됩니다. Terraform은 플랫폼용, Ansible이나 cloud-init은 호스트용, 워크로드엔 컨테이너 이미지. 실행 중 인스턴스는 그 정의의 한 번 구현일 뿐, 어떤 다른 인스턴스와도 구별할 수 없습니다.

불변 배포. 서버에 로그인해서 바꾸거나 패치하는 대신 새 버전을 만들고, 시험하고, 롤아웃해 옛 인스턴스를 통째로 교체합니다. 아무것도 축적되지 않습니다. 모든 환경을 유니크하고 설명 불가능하게 만드는 수동 변경의 조용한 축적, 즉 configuration drift가 구조적으로 불가능합니다.

복원 대신 재배포. 사람들을 놀라게 하는 payoff: 제대로 지어진 cattle-함대는 거의 백업이 필요 없습니다. 서버가 침해당하거나 망가지거나 잃어도 복원하지 않습니다. 코드에서 몇 분 안에 redeploy합니다. 정의가 백업이기 때문입니다. 복구 대화가 "이 기기를 어떻게 돌려받지?"에서 "교체를 얼마나 빨리 띄울 수 있지?"로 바뀝니다. 실제 사건 중 훨씬 나은 대화입니다.

랜섬웨어 표면도 극적으로 줄어듭니다. 암호화는 재현하기 어려운 게 암호화됐을 때만 해롭습니다. Git 리포지토리에서 만들어진 일회용 기기는 재현이 쌉니다.

모든 관심이 데이터로 향합니다 #

시스템이 일회용이 되면 대체 불가능한 모든 것이 데이터 안에 있습니다. 그건 자기만의 규율을 받을 자격이 있고, 대부분 조직이 정확히 답한 적 없는 질문에서 시작합니다. 우리는 무슨 데이터를 들고 있고, 어디에 살고, 누가 만지고, 시간에 따라 무엇이 되는가?

데이터의 생애주기를 추적하세요. 생성, 처리, 복사, 보관, 파기: 각 단계가 알려져야 하고 의도적이어야 합니다. 라이프사이클 추적은 여러 번 값을 낳습니다. PDPA 등이 기계가 아니라 데이터를 따르므로 규제 의무가 어디 붙는지 알려줍니다. 아무도 세지 않은 잊힌 사본, breach가 실제로 발생하는 곳을 드러냅니다. 그리고 내일 삭제 가능한 게 뭔지 말해줍니다. 흔히 가장 싼 위험 감소입니다. 존재하지 않는 데이터는 샐 수 없으니까요.

기계를 무의식적으로 말고 데이터를 의도적으로 백업하세요. 시스템이 코드로 정의되면 백업은 집중되고 정직해집니다. DB 덤프, 오브젝트 스토리지 복제, 설정 리포지토리, 시크릿 vault. 쓰레기까지 포함한 매것의 야간 이미지가 아니라 진짜 중요한 것들의 작고 검증 가능한 집합입니다.

데이터를 처리 시스템 밖에 두는 것을 고려하세요. 애플리케이션은 로컬에 거의 아무것도 안 둘 수 있습니다: state는 managed database에, 파일은 object storage에, secret은 vault에. 처리 계층에는 훔칠 게 없어서 침해된 application server가 보고 필요 사건이 아니라 운영 지장이 됩니다. 덤으로 저장을 위해 특별 설계된 데이터 서비스들이 versioning, immutability 옵션, 세밀한 access control처럼 어떤 범용 서버도 도달 못 할 더 강한 내장 보호를 보통 제공합니다.

세 개가 아니라 한 개의 함대를 운영하세요 #

이 안에 또 하나의 단순화가 숨어 있습니다. 함대 그 자체에 관한 것입니다. Windows-Linux 혼합 estate를 도는 조직의 비용 구조를 보고 복제를 세보세요:

두 개의 스킬셋. Windows 관리와 Linux 관리는 다른 직업입니다. 둘 다 지원은 각각 전문가를 뽑거나 양쪽 다 얕은 커버를 받아들이는 겁니다. 대략 같은 기기 수에 두 배 팀.
두 개의 toolchain. 패칭, 모니터링, 구성 관리, hardening baseline, agent 배포: 각각이 두 벌 존재하고 각자 라이선스, 유지, 업그레이드됩니다. 두 배 예산, 관리 인프라의 두 배 공격면, 조용히 뒤처질 수 있는 게 두 배.
두 개의 실패 양상. 사고 대응 플레이북, 포렌식 능력, DR 절차가 플랫폼별로 갈라집니다. 사건 중에 그 갈래가 정확히 당신이 없는 시간을 삼킵니다.

항공사 analogy가 여기서 값을 합니다. 성공한 항공사 중 모든 기종을 도는 데는 없습니다. 기종이 추가될 때마다 정비 프로그램, 예비 부품 재고, 승무원 자격, 훈련 파이프라인, 격납고 장비가 곱절이고 그 비용은 구매 결정이 기억에서 사라진 후에도 영원히 반복됩니다. 그래서 항공사들은 노선을 섬길 최소 기종 집합에 무자비하게 표준화합니다. IT estate도 같은 산수를 받을 자격이 있습니다. 표준 OS를 고르고 그 선을 지키면 모든 것의 ‘둘’이 ‘하나’가 되고 절감은 매년 복리로 쌓입니다.

표준화는 보안을 직접 강화하기도 합니다. 한 함대는 깊이 이해된 하나의 hardening baseline; 튜닝되고 신뢰된 하나의 패치 pipeline; 실제 estate에 맞는 한 세트의 탐지 규칙을 의미합니다. 매번 깊이가 커버리지를 이깁니다.

어디서 시작할까 #

워크로드 하나를 골라 disposable로 만드세요. 손으로 건드린 게 하나도 없고 완전 교체가 몇 분 걸릴 때까지 코드에서 재건하세요.
데이터를 정직하게 목록화하세요. 어디에, 어떤 시스템 위에, 누구 통제 아래 있는지, 내일 삭제 가능한 건 뭔지.
state를 application server 밖으로 적절한 access control과 immutability 옵션을 갖춘 전용 storage로.
함대 split 비용을 정직하게 계산하세요. 복제된 licence, tool, 인력을 통합 가격과 더해보세요. 항공사가 노선을 평가하듯 경영진에게: 반복 비용 versus 반복 수입.
미래 표준 설정: 새 시스템은 표준 함대에 합류, code-defined, 가능한 stateless. 예외는 적힌 사유가 필요합니다.

관심사 분리는 engineering의 가장 오래된 교훈 중 하나이고 security는 그걸 문자 그대로 적용해 이득을 봅니다: system은 임시고 data는 영구이며, 각자의 참된 본성대로 보호하는 게 둘 다 못하게 보호하는 것보다 쌉니다.

만약 그걸 만지는 모든 서버가 사라져도 kritikal 데이터가 살아남을지 궁금하신가요? 부담 없이 현황 점검을 요청하세요. LINE(@PureSecurity) 또는 이메일(hello@puresecurity.com)로 연락 주시면 됩니다.

저희 구성 및 아키텍처 평가가 data 위치와 처리 위치를 map하고 분리 경로를 설계하며, Linux hardening practice가 standardisation을 값지게 만드는 single-fleet baseline을 세웁니다. 또는 schedule an Engineering & Scoping Session으로 팀과 함께 계획하세요.