현대적 보안이란 무엇인가? 정의가 간단치 않으나 몇 가지 통념에 대해 반성하고 실질적인 위협에 대해 고민하고 대응했던 경험을 “현대적 보안”이란 단어에 녹여보려 한다. 현금성 자산을 온라인에서 다루는 극한 업종(한번 뚫리면 천문학적인 손실을 본다. 그것도 현금으로)에서 다년간 몸을 담근 경험을 바탕으로 이야기를 해나갈 것이다. 이러한 업에선 공격자가 상당한 자본과 자원을 동원할 동기가 있기 때문에 보안을 진지하게 생각할 수밖에 없다. “이렇게까지 하겠어?”라고 방심하면 바로 그쪽으로 공격이 들어오는 살벌한 시장이다. 오늘을 무사히 보냈어도 우리가 놓치고 있는 저 곳 어딘가에서 무슨 일이 벌어지는지 몰라 전전긍긍하는 매일을 보낸다. 이렇게 극한 상황에서 내가 한 고민과 나름의 해법이 누군가에게는 쓸모있는 시작점이 될 수도 있을 것이다.
현대적 보안은 새롭지 않은 개념과 프랙티스의 조합이다. 특히 Zero Trust에 가장 공감한다. 지금은 Buzzword가 된 감이 있으나 이 개념을 진지하게 받아들이고 고민한다면 여러 측면에서 개선된 시스템을 구축할 수 있다. 이밖에도 DevSecOps, 개발과 감사 조직의 조화로운 협력 등을 믿는 체계이다.
뜬구름 잡는 소리를 하기 전에 이해를 돕기 위해 무엇이 현대적 보안이 아닌지부터 간략히 알아보자.
무엇이 현대적 보안이 아닌가?
- 데이터베이스에 집착한다. 데이터 스토어의 종류가 다앙한데 RDBMS 만 중요한 자산으로 취급한다.
- 오래되고 안정적인 기술을 신뢰한다. IPSEC 처럼 이제는 안전하지 않은 기술을 신뢰하고 Wireguard 와 같은 새로운 기술은 검증되지 않았다며 불신한다.
- 망의 경계를 기준으로 사고한다. 망 분리가 달성하려는 목적보다는 그 수단에 집착한다.
- 폐쇄망이 개방망보다 안전하고 믿는다.
- 보안 조직이 감사 권한을 권력이라 착각하고 이를 행사하는데 심취한다.
- 개발 조직이 감사 조직을 경멸하고 백도어를 확보하려 한다.
누구도 믿지 말라
커뮤니티에서 접근통제 이야기를 할 때면 IAM, MFA, IP 제한 같은 수단으로 충분히 방비하고 있다는 말을 듣곤 한다. 이러한 수단을 갖추려는 노력은 훌륭하다. 그러나 거기까지는 비교적 쉬운 일이고 시작점에 불과하다. 노력을 폄하하려는 것은 결코 아니며 단지 상황을 냉정하게 보자는 것이다. 방어하는 측의 제일 큰 이슈는 한 곳이 뚫렸을 때 그 여파가 다른 곳까지 전이되지 않도록 하거나 전이될 때까지 최대한 시간을 버는 것이다. 일반적으로 네트워크 경계선을 따라 관문을 세운다. 이를테면 VPN을 이용해 인스턴스에 접근할 때까지 끈질기게 추적한다. 그러나 일단 안전한 접속이라고 판단한 후에는 별다른 제약을 가하지 않는다. 그런 까닭에 정교한 APT 공격에 전체 시스템이 한번에 무너지곤 한다. 한 곳만 뚫으면 나머지는 쉽다. 정문 방비를 엄격하게 한다고 자신한다면 그것이 자만은 아닌지 스스로에게 질문을 던져보자. 다양한 사례를 검토해보면 공격자 입장에서 첫 침투까지의 작업은 지루하긴 해도 비교적 쉬운 일이다. 첫 관문의 방비를 계속해 보완해 나가되 첫 관문이 이미 뚫렸으리라는 가정을 하고 다음 단계에 만전을 기해야 한다.
기본적인 원칙은 단순하다. 각각의 자원은 스스로를 보호한다. 내부 시스템일지라도 외부 시스템으로 취급한다. 검증하고 모니터링하라.
그런 의미에서 AWS 같은 퍼블릭 클라우드가 온프레미스 솔루션보다 앞서 간다. 폐쇄망을 운영하는 온프레미스가 더 안전하다는 인식이 널리 퍼진 현상황을 감안해볼 때 이는 대담한 헛소리처럼 들릴지 모른다. ISO27001 선임심사원 과정을 이수하러 광화문에 출퇴근을 할 무렵, 한 카페에서 증권사 임직원과 이 회사에 장비를 공급하는 모 외국계 대기업 임직원의 대화가 어렴풋이 떠오른다. 그들은 여전히 값비싸고 소위 안정적인 장비와 솔루션이 안전을 보장한다고 믿었다. 그러나 폐쇄망을 운영하는 온프레미스가 더 안전하다는 주장은 정문 뚫기가 무한히 어렵다는 가정 하에서만 유효하다. 단 한번의 성공적인 일격이면 대마는 죽는다. 단 한번의 일격따위는 있을 수 없다고 주장할지도 모르겠다. 그러나 이런 주장은 주가가 10년 간 대세상승했으니 내일도 주가는 오를 것이라는 가정만큼이나 터무니 없이 낙관적이다.
퍼블릭 클라우드의 강점은 각각의 리소스를 접근할 때마다 검증하고 모니터링하는 체계가 잡혀있다는 것이다. AWS에서는 IAM이 대표적인 상품이고 Zero Trust의 개념을 최초로 시장에 퍼뜨린 회사는 다름 아닌 Google이다. 작년 한해에 시중에 나온 각종 온프레미스 솔루션을 검토할 기회가 있었다. 그런데 역시 가장 큰 문제는 보안이었다.
우선 대부분의 솔루션이 감사 기록을 제대로 제공하지 않았다. 감사 기록을 아예 제공하지 않는 솔루션은 없었지만 퍼블릭 클라우드에 비해 그 세밀함이 부족했으며 통합된 접근방법을 제공하는 곳도 많지 않았다. 로그가 있어도 접근하고 가공하기가 쉽지 않다면 말짱 도루묵이다. 우리가 수집하는 메트릭만 수십만 가지인데 이것을 매일 같이 눈으로 확인할 수는 없지 않은가?
어떤 제품은 IDP와 통합하는 보안체계를 지원하지 않는다. 아니, 그런 보안체계를 지원하는 제품이 더 적다. 누가 무엇을 수행했는지 추적하기 힘들다. 이런 제품 중 상당수는 내부망에서 벌어지는 행위는 안전하다 가정하고 기능 수행에만 초점을 맞춘다. 막말로 내부망에 들어갈 수 있으면 익명성을 보장 받으며 스토리지 레이어부터 마구잡이로 헤집고 다닐 수 있다. “내부망에 못 들어가게 하면 되는 것 아니냐?”라 한다면 마지노선과 만리장성을 보라. 나보다 기동력이 좋은 공격자가 항상 있기 마련이고, 내부의 배신자가 없다고 가정하기에는 걸린 것이 너무 많다.
퍼블릭 클라우드의 예를 들었지만 요점은 단순하다. 서로를 검증하라. 시스템과 개인 모두를 검증하라. 때로는 중앙 관리체계에 더해 각 하위조직이 별도로 구성한 보안 체계를 섞는 것도 좋다. 공격자가 모든 것을 파악하기 힘들게 하고, 언제든 지뢰밭을 밟을 수 있다는 긴장을 심어줄 수 있을 것이다.
동기화된 실패를 피하라
파도에 흔들리지만 가라앉지 않는다
자동화와 관리용이성은 적극적으로 추구할 미덕이다. 그러나 이 둘을 쫓다 동기화된 실패에 빠지지 않게 조심하자.
VPC Peering과 같은 네트워크 통합은 관리를 용이하게 하고 외부 통신을 내부 통신으로 대체해 비용을 감소시키고 보안을 강화한다. 그러나 이와 동시에 공격자에겐 프리티켓을 제공하는 측면이 있다. 아무리 네트워크 보안을 강화한다 해도 네트워크와 네트워크를 엮으면 노출면적이 상당히 넒어진다. 일반적으로는 한두 가지 서비스를 엮어야 하는 상황이라 네트워크를 통합한다. 만약 이런 상황이라면 네트워크를 엮는 대신 해당 서비스만 완전히 격리하고 선별해 묶는 게 낫다. 그리고 각 서비스는 서로를 무조건 신뢰하기보다는 상호검증하여야 한다. 앞서 서술한 원칙에 따라 한쪽의 실패(보안 측면이든 운영 측면이든)가 다른 쪽으로 전이되지 않게 하자.
네트워크 통합 이야기를 시작한 김에 대부분의 조직에서 간과하는 구체적인 사례를 하나 더 들겠다. 사무실에서 데이터센터로 안전하게 통신하기 위해 VPN에 의존하는 경우가 많다. 데이터센터가 하나라면 나쁜 선택이 아닐지 모른다. 그런데 데이터센터가 여럿이라면 어떠할까? 퍼블릭 클라우드를 이용하는데 리전은 하나라도 계정이나 VPC가 여러 개라면 어떠할까? VPN을 네트워크마다 따로 두겠지만 결과적으로는 여러분/작업자의 로컬 랩탑을 중심으로 모든 네트워크가 통합되는 효과가 발생한다. 로컬 랩탑에서 네트워크 A와 B를 동시에 접속하면, 네트워크 셋(사무실, A, B)이 하나의 네트워크로 통합된다. 동시에 접속하지 않더라도 네트워크 A에 침투한 공격자가 로컬 랩탑을 거쳐 네트워크 C까지 침투한다. 이런 식의 공격이 얼마나 효과적인지는 공격자의 입장에서 모의 시뮬레이션을 해보면 체감할 수 있을 것이다.1또는 전문 컨설팅 업체의 도움을 받아도 좋다.
라우팅 등의 설정을 매우 세밀하게 하지 않고는 방금 서술한 바와 같이 VPN은 믿음을 배신한다. 차라리 이럴 바엔 내부 시스템을 퍼블릭 로드밸런서로 여는 편이 나을지도 모른다. 적어도 서비스의 실체는 로드밸런서 뒤로 숨을 수 있기 때문이다. VPN을 매우 세밀하게 설정하면 어떻냐고 반론을 펼 수 있지만 시스템이 클수록 VPN과 그 설정의 숫자가 기하급수적으로 증가하기 때문에 실질적으론 지속가능한 시스템이 아닐 것이다. 퍼블릭 로드밸런서는 극단적이라 생각한다면 CloudFlare Access / Argo 서비스와 같은 접근방법도 있고, 대안은 얼마든지 있다.
핵심은 모든 것을 통합해 관리하려는 편의주의를 버리자는 것이다. 자동화와 생산성이 반드시 일원화된 관리를 뜻하는 것은 아니다. 우리에겐 두 마리 토끼를 잡을 수 있는 창의력과 영감이 있다.
SaaS를 활용하라
온프레미스와 기밀성이 보안의 핵심요소라 생각하는 사람이 업계에 많다. SaaS를 활용해야 보안을 강화할 수 있다는 주장은 매우 생소하거나 세일즈 문구처럼 느껴진다. 그러나 단순한 이론모형이 아니라 모의실험 등의 실전적인 검증에 바탕을 둔 주장이다.
AWS의 Systems Manager를 이용해 EC2 인스턴스에 접근한다 치자. 이 경우에 AWS 콘솔 또는 API 로그인 과정에서 MFA와 IP 제한 등을 이용하는 베스트 프랙티스를 제안받는다. 그런데 이 프랙티스를 수행하는 방법도 한 가지가 아니다. AWS의 기능만 활용해도 되고 Okta 같은 IDP와 AWS를 연계해도 된다. 규제상의 문제가 없다면 후자를 선택하자. 논리는 단순하다. SaaS 와 같은 외부 서비스를 보안 체인 안에 넣으면 공격자의 관심과 자원을 분산시킬 수 있는 까닭이다. 공격자가 여러분의 시스템에 침투하려면 써드파티 서비스부터 뚫어야 한다. 보안 정책과 시스템이 매우 상이한 두 개의 시스템을 동시에 공격해 들어가기란 매우 어렵다. 특히 보안 전문 인력이 많은 IDP 등의 SaaS 서비스라면 우리의 시스템보다도 더 많은 자원을 소모해야 할 수도 있다. 극단적으로 생각해 가장 유명한 IDP인 OneLogin과 Okta를 모두 연동한다 치자. 상대는 이 둘을 뚫은 후에 우리의 시스템을 뚫어야 한다. 시간지연이 길수록 어느 한쪽의 침투경로가 발견돼 그동안의 노력이 모두 물거품이 될 가능성이 높다. 그러므로 공격자가 투입해야 하는 자원의 양은 기하급수적으로 증가한다.
물론 외부 서비스에만 의존하라는 말은 아니다. 다만 외부 서비스를 전체 보안 체계 사슬의 일부로 엮어 넣으면 강력한 지지대를 세울 수 있다는 뜻이다. 매우 까다로운 규제안이 있어 외부 서비스의 전면적인 도입이 쉽지 않다면, 가장 외각 방어선에만 외부 서비스를 두고 규제기관과 타협해 볼 수도 있다. 외부 서비스에 전적으로 의존하지 않는다면 딱히 반대할 명분이 없기 때문이다.2물론 세상에는 말이 안 통하는 사람과 기관이 있긴 하다.
물은 위로 흐르지 않는다
중력이 거꾸로인 행성에 살지 않고는 물은 위에서 아래로 흐른다. 너무나 자연스러운 현상이라 대부분의 사람은 이러한 사실을 굳이 서술할 동기 자체가 없다. 그런데 미래지향적인 소프트웨어 산업에서는 어찌된 영문인지 자연을 거스르는 설계가 널리 퍼져 있으며 수많은 사람이 이에 의문 한번 제기하지 않느다. 심지어 베스트 프랙티스라며 이를 권하기까지 한다.
이러한 부자연스러운 양태는 CI/CD 파이프라인 구축 사례 대부분에서 발견할 수 있다. 개발 환경에서 스테이징과 운영으로 넘어가는 일련의 과정에서 하위 시스템이 상위 시스템에 침투적인 방식으로 지시를 내린다. 빌드 서비스가 운영 환경의 크레덴셜을 들고 운영 환경에 직접 접속해 배포를 진행한다. 빌드 서비스가 위치한 개발 환경이 운영 환경으로 가는 사실상의 고속도로인 셈이다.
게다가 다수의 팀과 애플리케이션이 빌드 서비스 하나를 공유하는 일반적인 관례3비용과 편의를 감안하면 자연스러운 선택일지 모른다.를 고려하면 여기는 그야말로 지뢰밭이다. 개발 환경은 상대적으로 보안이 느슨하고 각종 실험을 진행하는 곳이다. 따라서 상대적으로 취약하다. 이런 곳으로 우회해 공격하면 운영 환경 전체를 위협할 수 있는데 굳이 마지노선을 정면으로 뚫고 갈 필요가 있는가? 중앙집중적인 빌드 시스템에서 위험은 무제한적이며 이 위험을 실현하는데 드는 비용은 지나치게 저렴하다.
이 문제는 단순히 Push 방식의 배포 체계를 Pull 방식으로 바꾸기만 해도 상당히 해소된다. 개발 환경은 빌드 산출물을 생성하는 책임만 다한다. 산출물이 준비되면 운영 환경의 배포 시스템이 그 산출물을 가져와서 검증하고 배포하면 된다. 상위 환경의 배포 및 보안 체계를 하위 환경에 노출할 이유가 없다.
CI/CD 파이프라인은 하나의 예일 뿐이다. 중력 원칙4물리가 아닌 소프트웨어 분야에서는 법칙은 아닐 것이다.은 언제 어느 곳에서나 중요한 지침이 되어야 한다.
이를테면 Ansible과 같은 Provisioning 도구에도 중력 원칙을 적용할 수 있다. 시스템 밖에서 안으로 타고 들어가는 ssh 방식상 Ansible은 본질적으로 바람직하지 않다. 이를 경감한 구조를 고안하지 않는 이상은 그러하다. 그에 비해 Puppet Standalone은 구조적으로 더 나은 선택이다. Puppet Standalone은 각각의 대상 리소스(예. EC2 인스턴스)가 미리 정의하고 검증한 부트스트래핑 산출물을 S3와 같은 중앙 저장소에서 가져와서 제 할 일을 한다. 이 과정에서 Puppet Agent는 불필요하게 많은 권한을 요청하지 않는다. 스스로 Provisioning하기 때문에 각자 자기 할 일만 하면 된다. 자기 자신과 무관한 외부 리소스에 대한 권한을 요청할 이유가 없다.
Puppet Standalone은 어느 한 곳이 뚫려도 피해가 제한적이다. S3 버켓이 노출됐을 때가 가장 위험하다. 단위 시스템 별로 접근가능한 S3 버켓을 제한하면 노출 범위를 제한할 수 있으며 그 어떤 경우에도 중앙에 모든 자산을 쌓아놓는 방식에 비하면 상대적으로 안전하다. Puppet Standalone 과 같은 Pulling 방식은 각각의 리소스가 상호검증하는 체계를 짜넣을 여지까지 있다. 이는 매우 중요하고 강력한 지지대를 곳곳에 추가로 세울 기회가 있다는 뜻이다.
권한보다는 합의와 시스템이다
과거에는 모든 것이 권한으로 정의됐다. 운영서버에 들어갈 권한, VPN을 열 권한 등등. 그러나 이러한 권한 체계는 실제로는 작동하지 않는다. 서버가 터졌거나 보안침해가 발생한 것 같은데 언제 기안 올리고 승인 받고 설정하고 수행하는가? 예외적 상황에는 예외적인 조치가 가능하다 해도 그 체계가 복잡하다면 대응 지연은 어쩔 수가 없다.
다른 측면에서 보면 권한 체계를 아무리 잘 잡아도 침해사고를 막는데는 한계가 있다. 여기에 금고가 있다. 금고에 들어가면 금괴를 가지고 나올 수 있다. 그래서 조직장5은행장이라 해도 좋다만 금고 열쇠가 있다. 자, 그러면 안전한가? 여기에는 몇 가지 문제가 있다. 조직장이 탄 비행기가 추락하면 금고에 접근하기 힘들어진다는 운영상의 문제를 차치해도 조직장을 100%로 믿어도 되냐는 문제가 남는다. 심정적으로야 믿고 싶지만 그래도 되는가? 만약 금고가 뚫린다면 그건 내부자의 소행인가? 아니면 외부인의 악의적인 공격에 조직장이 당한 것인가? 그도 아니면 다른 경로로 공격이 들어온 것인가? 이렇게 책임과 권한이 한 사람에게 몰리면 조직뿐 아니라 그 개인에게도 상당한 부담이 된다.
그러면 어쩌란 말인가? 우리가 놓치고 있는 게 있지 않은가? 본질적인 문제는 권한 체계 그 자체일지 모른다. 여러분이 야식 배달업을 하는 “야식조아”라는 서비스 개발팀의 팀장이라 하자. 야식업의 특성상 야간 장애는 매우 중대한 사건이고 언제든 문제가 생기면 여러분은 서비스에 접근해 조치를 취해야 한다. 그렇기 때문에 기안을 미리 올려 VPN과 기타 서비스 접근권한을 받아두었다. 각종 인증키가 로컬 컴퓨터에 있다는 말이다.6물론 암호화를 해 필요할 때만 복호화하고 꺼내쓰면 조금은 더 안전할지 모른다. 여러분의 랩탑은 운영환경이나 다름 없다. 이제부터 여러분은 랩탑과 홈네트워크 모두 공격자로부터 안전한지 덜덜 떨어야 한다. 공격을 감시하는 감사 조직 입장에서도 난처하다. 미리 키를 안 주자니 야간 장애 대응이 늦어질테고, 키를 주자니 매번 합법적인 접근인지 확인하기가 힘들다. 우리 집 열쇠를 들고 현관문을 여는 사람이 모두 우리 가족이라 믿는다면 감시 카메라 같은 다른 방법 장치는 필요 없을텐데 현실은 그렇지 않다.
중요한 시스템이라면 특정 기간 동안 특정 권한을 부여하는 방식보다는 합의구조를 도입하는 편이 낫다. 예를 들어 야간에 담당자가 VPN 시스템에 접근하면 감사 조직을 포함해 대여섯 명에게 알람이 간다. 그 중 셋이 승인/합의 버튼을 누르면 담당자는 VPN과 내부 시스템에 접근할 수 있다. 중요한 시스템이라면 합의자는 이 접근이 적법한지, 접속하려는 사람이 실제 우리가 아는 그 사람이 맞는지 확인한다. 전화통화라도 하고 합의해주면 된다. 이러한 체계에서는 담당자에게 사전에 시스템 접속 권한을 줄 필요가 없다. 단지 접속 권한을 받기 위한 합의 시스템에 대한 접근 권한만 부여하면 된다. 실제 시스템에 접근할 때는 임시 권한 부여되고, 자동화된 시스템 감사와 사람이 직접 확인하는 감사를 조합할 수 있다.
이것은 하나의 예일뿐이다. 자산을 온라인과 실시간으로 다루는 극단적인 환경이 아니라면 좀더 느슨하게 접근해도 될지 모른다. 그러나 안전성 여부를 떠나 편의성에서도 합의 시스템이 더 나을 것이다. 모든 것을 사전에 완벽하게 조율하고 설정해야 하는 기존 시스템을 다루다 보면 화가 치밀 수밖에 없다고 믿는다.7간혹 이러한 자잘한 일에서 사소한 즐거움을 찾는 통제광이 있긴 하다.
상상력과 영감을 믿자
보안이라 하면 딱딱하고 내 일이 아니고 성가시고 가급적 피해야 할 일인가? 상당히 많은 사람이 그러한 감정을 느낀다. 그러나 그 감정이 두려움에서 비롯되지 않는지 차분히 생각해보자. 조직의 경계를 넘어선 협의가 필요하기 때문에 힘든가? 일이 많은데 보안까지 감안하려니 벅찬가? 실은 생산성과 보안을 모두 잡기가 어렵기 때문에 더 즐겁고 보람찰 수 있다. 그리고 가장 중요하고 희망적인 소식은 두려움을 걷어내고 나면 실제 상황은 훨씬 좋다는 것이다.
핵심은 상상력과 영감이다. 뜬구름 잡는 소리 같겠지만 이것이야말로 내가 할 수 있는 최선의 조언이다. 어렵기 때문에 새로운 관점에서 문제를 바라봐야 하며 때로는 매우 편의주의적인 꼼수를 짜내야 한다.
ssh와 같이 외부에서 내부로 접근하는 수단을 어떻게 보호할 것인지 고민인가? 차라리 고민의 방향을 바꾸면 어떤가? 내부에서 외부로 접속을 뚫는 것은 어떠한가? 잘 찾아보면 상용/비상용 솔루션이 있다. 내가 처음하는 생각은 아니지만 발상을 해내야 그러한 솔루션을 찾아낼 수 있다.
한술 더 떠보자. ssh가 애초에 필요한 이유는 무엇인가? 장애시 문제 진단을 하러 접근하는 경우가 99%인가? 그렇다면 로그 분석 등 모니터링 체계를 제대로 갖추기만 해도 대부분의 문제가 해결되지 않는가? HA 구성과 프로비저닝을 제대로 갖추면 어떠한가? 문제가 되는 노드를 새 노드로 교체하는 것만으로도 장애 대응이 된다면 굳이 ssh 접속을 할 필요가 있는가?
코로나 19 때문에 재택근무가 많아져 고민인가? 업무망에서만 접근가능하던 백오피스를 VPN으로 열어주려니 비개발자에게 교육을 제공하고 전에 없던 접근제어체계를 구축해야 하니 힘든가? 그런데 말이지. VPN이 유일한 접근제어 솔루션인가? VPN 대신 AWS AppStream 을 쓰면 어떠한가? AppStream 서비스에만 백오피스의 방화벽을 열면 되므로 많이 설정할 게 없다. 접근제어와 로깅은 클라우드 서비스 사업자가 제공하므로 구현하느라 애쓸 필요가 없다.
보안은 지루한 일이 아니다. 되려 상상력이 끔찍히도 많이 요구되는 흥미로운 업무이다. 더 많은 사람이 이를 깨닫는 조직은 현대적 보안을 더 손쉽게 구현할 것이다.
상부상조하자
개발 조직과 보안 조직은 한 몸일 수 없다. 전자는 본질적으로 수행 조직이고 후자는 감사 조직이기 때문이다. 그러나 그런 까닭에 서로를 존중하고 함께 임무를 수행해야 한다.
안타깝게도 현실에선 서로가 서로를 경멸하는 곳이 많다. 그런 곳에선 기만이 성횡하며 진정한 성취보다는 일신의 안전과 편의만을 쫒는다. 반면 서로가 존중하고 서로의 부족함을 대신 채워주려는 적극적인 동기가 있는 곳은 더 즐겁고 더 안전하며 성취감으로 가득하다. 보안 조직은 어쩌면 귀찮을 수 있는 일을 차분하고 꾸준히 수행한다. 그들이 없다면 개발자는 Compliance와 Governance에 대응해 어디서부터 무엇을 들여다 볼지 몰라 헤맬 것이다. 그들이 매일 같이 또는 주기적으로 검토하고 작성해야 하는 문서가 얼마나 많은지 아는가? 감이 온 온다면 그들과 개인적인 친분을 더 쌓도록 노력하자. 고마운 마음이 절로 들 때까지.
개발 조직은 보안 조직의 생산성을 극도로 끌어올릴 힘이 있다. 로그가 어떤 형태여야 분석하기 좋은가? 어떤 데이터 플랫폼이 그들이 하려는 작업에 효과적인가? 자산 목록을 자동으로 뽑아주는, 그래서 보안 조직의 잡무를 극적으로 줄여줄 수는 없는가?
서로가 서로에게 도움이 되는 것을 넘어서 현대의 Dev/Ops 환경에서는 협력이 필수적이다. 생산성이든 비용이든 아니면 단순히 재미이든 뭔가를 얻기 위해 Kubernetes 를 도입했다고 하자. Kubernetes 를 안전하게 운영하려면 어떻게 해야 하는가? Network Policy, PodSecurityPolicy, RBAC 등 새로운 개념이 많다. Kubernetes를 운영하는 주체가 이를 보안 조직에 알리고 활용처를 같이 고민해보자고 먼저 시작하지 않으면 어떤 것도 제대로 진행되지 않을 것이다. 또한 보안 조직이 적극적으로 이를 함께 검토하지 않는다면 개발 조직은 Kubernetes 를 Compliance와 Governance에 맞지 않는 괴상한 형태로 운영하게 될 것이다. 서로가 서로를 찾고 협력해야만 성공적으로 일을 해낼 수 있다. 이는 결코 선택의 문제가 아니다.
마무리하며
현대적 보안은 잘 정리된 이론은 아니다. 이것은 개인적 경험에 바탕을 둔 조언에 가깝다. 선별적으로 채택을 하던 모두 무시를 하던 각자 선택할 문제이지만 적어도 이 글이 보안이란 문제와 그 주변여건에 대해 한번 더 고민하는 계기가 되길 바란다.
