보안의 비극은 DevOps라는 시험대에서 끝난다

보안은 예전 같지 않습니다. 어쩌면 언제나 이랬는데, 젊은 시절의 이상주의가 서서히 바래면서 달라 보이는 것일 수도 있습니다.

보안은 두 갈래로 나뉩니다. 한쪽 길에서 우리는 조직을 안전하게 지키기 위해 노력합니다. 악의적 행위자를 차단하고, 데이터와 자산을 보호하며, 위협은 물론 사용자 자신의 실수로부터도 사용자를 지켜냅니다. 다른 쪽 길에는 컴플라이언스가 있습니다. 조직이 규제, 계약 및 기타 표준을 충족하도록 보장하는 일입니다. 두 길 모두에서 우리는 위험을 관리합니다. 침해와 서비스 중단의 위험, 또는 규제 벌금의 위험입니다.

보안의 비극은 공유지의 비극을 반영합니다. 위키백과에서 인용하면 다음과 같습니다.

보안 컴플라이언스의 대부분은 보안 위험을 줄이기 위해 설계되었습니다. 적어도 문서상으로는 그렇습니다. 그러나 시간이 지나면서 우리는 표준이 거듭되고 규정이 거듭될수록 위험이 컴플라이언스로부터 분리되는 것을 목격해 왔습니다. 컴플라이언스 표준의 본질 자체가 조직이 자사의 위험에 맞게 보안 조치를 조정하는 것을 가로막습니다. 언제나 그렇다는 말은 아니지만, 대체로 그러하며 조직 규모가 커질수록 더욱 그렇습니다. MFA나 오늘날 흔히 사용되는 기타 조건부 제한을 적용한 사용자에게 90일마다 비밀번호 재설정을 요구하는 것이 보안을 개선한다는 증거는 없습니다. 비밀번호 복잡성 요건을 고안한 당사자는 말 그대로 그것을 후회하며 효과가 없다고 말합니다. 클라우드 제공업체의 모든 스토리지 볼륨에 기본값이 아닌 암호화를 적용하도록 요구하는 것에는 증거도, 타당한 과학적 근거도 없습니다.

보안은 공유되는 유한한 자원입니다. 우리에게 주어진 예산, 보안 전문 인력, 그리고 비보안 인력이 다른 목표를 희생하면서까지 보안에 할애할 수 있는 시간은 한정되어 있습니다. 컴플라이언스 쪽으로 더 많이 끌어갈수록 보안에 쓸 수 있는 몫은 줄어듭니다. 컴플라이언스가 보안과 어긋날수록 보안 위험을 줄이는 노력은 적어집니다.

이것이 바로 보안의 비극입니다. 우리는 위험을 컴플라이언스로부터 분리했고, 그 결과 컴플라이언스 미준수 자체가 위험이 되어버렸습니다. 실제의 더 큰 위험이 컴플라이언스로부터 멀어질수록 컴플라이언스 체계는 더 경직되고, 방어에 쓸 수 있는 보안 자원은 줄어들며, 다른 팀으로부터 얻는 보안 활동에 대한 지원도 줄어듭니다.

좋은 사례가 Chris Farris와의 대화에서 나왔습니다. 요약하자면 이렇습니다.

개발자들은 보안에 신경을 씁니다. 그들을 짜증나게 하는 것은 컴플라이언스입니다. 그들이 애플리케이션을 안전하게 만들도록 도우면 그들은 협조합니다. 반면 컴플라이언스 담당자가 요구한다는 이유로 주말에 4시간 동안 서비스를 중단하고 암호화를 적용해 데이터베이스를 다시 구축하라고 지시한다면, 그저 그들을 화나게 할 뿐입니다.

모든 컴플라이언스가 어리석은 규칙이라는 말은 아닙니다. 다만 일부 컴플라이언스 규칙은 어리석으며, 위험과 분리된 채 좋은 규칙을 잘못 적용하는 것은 정말로 어리석습니다.

DevOps가 보안의 미래를 가늠하는 시험대가 되는 이유는, 클라우드와 DevOps의 세계에서는 개별 애플리케이션 팀이 보안의 상당 부분을 포함해 전체 스택을 책임지게 되기 때문입니다. 새로운 서버, 네트워크, 방화벽은 git commit 한 번과 몇 번의 API 호출이면 만들어집니다. 이는 또한 해당 팀들이 자체 보안과 컴플라이언스를 관리해야 하는 더 큰 부담을 지게 만듭니다. 우리에게는 여전히 중앙화된 보안과 공유 보안 자원이 있지만, 최전선에 이르러서는 DevOps 팀에 훨씬 더 의존하게 됩니다. 클라우드에 거대한 DMZ를 만들 수는 없습니다. 내부 네트워크와 외부 네트워크의 경계는 더 이상 획일적인 영역으로 분류할 수 없습니다. 네이티브 클라우드 서비스를 기반으로 구축된 많은 애플리케이션은 이제 네트워크라는 것을 아예 가지고 있지 않으며, 애플리케이션 팀이 코드형 인프라를 통해 배포하는 JSON으로 작성된 IAM 규칙과 리소스 정책에 의존합니다.

그래서 최근 제가 진행한 클라우드 및 DevOps 중심의 컴플라이언스 프로젝트 상당수는, 먼저 제대로 된 보안을 구현한 다음, 실제로는 컴플라이언스 조문을 문자 그대로 충족하지 않더라도 — 심지어 더 안전한데도 — 충족하는 것처럼 보이는 보고서를 어떻게 작성할지 궁리하는 일에 가깝습니다.

가능한 해결책은 두 가지입니다.

첫째는 클라우드와 DevOps에 더 잘 맞도록 보안 표준을 개정하고 어리석거나 적용 불가능한 규칙의 수를 줄이는 것입니다. 이러한 작업이 일부 진행되고 있지만, 저는 이것이 우리가 기다릴 여유가 없는 세대교체를 필요로 한다고 생각하게 되었습니다. 포기하지는 맙시다. 다만 마냥 기다릴 필요도 없습니다.

다른 하나는 자동화를 활용해 개인이 지는 보안 및 컴플라이언스 부담을 최대한 덜어내되, 빠르게 구축할 수 있는 자유와 통제권은 그대로 유지하는 것입니다. 보안에 투입되는 전체 자원을 줄이자는 뜻이 아니라, 자동화와 기타 기술을 활용해 가치가 낮은 일에 개인이 시간을 소모해야 하는 요구를 줄이자는 뜻입니다.

결국 한정된 자원의 시간과 집중에 관한 문제입니다. 그리고 솔직히 무엇이 더 가치 있을까요. 제대로 된 침투 테스트일까요, 아니면 컴플라이언스 감사일까요? 이제 침투 테스트에 얼마를 쓰고 감사에 얼마를 지불하는지 살펴보십시오.