보안 규칙 1: 당신은 지금 그것을 위반하고 있을 가능성이 높습니다.

이제 여러분은 보안 규칙 제로에 대해 충분히 들었을 테니 그것을 암기했을 겁니다 . 당신은 그것을 암기하고 있죠?

혹시나 해서 기억을 되살려 보겠습니다.

사용자 입력을 믿지 마세요. 항상.

훌륭한. 이제 기본 규칙을 확립하고 해결했으니 보안 규칙 1에 대해 이야기해 보겠습니다. 짐작하셨겠지만 보안에는 여러 가지 규칙이 있습니다. 그럼, 첫 번째 규칙으로 넘어가볼까요?

보안 규칙 1: 자격 증명을 하드 코딩하지 마세요. 항상. 

토큰화(API에서 인기 있는 방식)와 연합 ID를 통한 액세스 제어 시대에 이 규칙은 공개 앱에서 거의 어겨지지 않습니다. 이 규칙이 종종 어겨지고 무시되는 곳은 조직 내부 입니다. 그리고 NetOps가 조직의 디지털 전환 이니셔티브를 지원하기 위해 스크립팅 및 자동화를 사용하여 IT를 최적화하는 역할을 수행함에 따라 이는 빠르게 문제가 되고 있습니다.

제가 인터넷에서 찾은 매우 실제적인 사례 중 하나를 들어 설명해 보겠습니다. 제가 하나라고 말하는 이유는 포괄적인 목록을 제공할 시간도 여유도 없기 때문입니다. 그런 관행이 널리 퍼져 있죠.

오른쪽에는 엄청나게 흔한 보안 실수가 있습니다. 일반 텍스트, 하드코딩된 자격 증명입니다. 직장 환경에서는 용납할 수 없다는 것을 인정하는 의견조차 없었고, 더 안전한 인증 방법을 사용해야 한다는 고개 끄덕임도 없었습니다.

이것은 NetOps 측면에서 저를 깊이 괴롭힙니다. 왜냐하면 공유 기업 네트워크를 조작할 때 폭발 반경이 훨씬 더 커지기 때문입니다.

이런 종류의 보안 문제가 발생하는 이유 중 하나는 NetOps가 자동화를 받아들이고 있는 것은 사실이지만 반드시 전략적으로 채택하고 있지는 않기 때문입니다. 우리가 보고 있는 것은 상당수의 NetOps 전문가가 Python을 선택하고 이를 기존의 CLI 기반 구성 및 관리 방법과 결합하고 있다는 것입니다.

명령줄에 자격 증명을 입력하는 것처럼 동일한 자격 증명을 스크립트에 입력하고 그걸로 끝냅니다.

결국 이는 문제가 될 것이다. 이런 관행을 누군가가 악용하는 광경을 보게 될 것이고, 그 소식은 며칠 동안 우리의 뉴스 피드에 실릴 것입니다. 그런 일이 전에도 일어났으니까요. OneLogin을 기억하시나요? 스크립트는 자격 증명과 함께 저장하지 않았지만, 파일은 자격 증명과 함께 저장했습니다. 얼마나 엉망진창이 되었을지 상상해 보세요.

문제는, NetOps가 스크립트에 명령줄 자격 증명을 넣는 것에 꽤 자신감을 가질 수 있지만, 그 스크립트는 결국 어디에 저장될 것인가입니다. 이것이 제대로 관리되고 있나요? 코드로서의 인프라를 좋아하시나요? 버전이 관리되어 저장소에 보관되나요?

NetOps에서 Github을 채택하는 비율이 높다는 것을 보여준 Network to Code 커뮤니티 설문 조사를 기억하실 겁니다.

그럼 우리 스스로에게 물어보죠. 우리의 저장소는 어디에 있을까요? 사이트 외부에 있나요? 현장? 어떻게 보호되는가? 그리고 누군가가 그것을 손에 넣으면 폭발 반경은 어떻게 되는가?

사업을 유지하고 서비스하기 위해서는 스크립트와 자동화를 통해 운영을 확장해야 합니다. NetOps는 그 방향으로 나아가야 하지만, 어디에든 저장된 일반 텍스트 자격 증명의 결과를 심각하게 고려하지 않고는 그렇게 해서는 안 됩니다.

최소한 스크립트는 호출 시 자격 증명 입력을 요구해야 합니다. 자격 증명은 절대로 파일이나 스크립트에 저장해서는 안 되며, 일반 텍스트로는 더더욱 저장해서는 안 됩니다. 가장 좋은 방법은 보다 고급 자격 증명 관리 솔루션을 사용하여 인증을 강제하고 내부 스크립트 전체에서 토큰화를 사용하는 것입니다. 하지만 저는 지금이 NetOps에서 자동화를 대량으로 도입하는 초창기라는 걸 알고 있으며, 한 번에 한 단계씩 진행해야 합니다.

그 점을 염두에 두고, 적어도 호출 시 자격 증명을 요구하세요. 현재 구현 방식으로는 너무 어렵다면, 한 걸음 물러나 IT에 대한 전반적인 자동화 전략을 살펴볼 때가 되었을 것입니다. 첫 번째 질문은: 당신도 하나 가지고 있나요? 아니면 당신이 하는 일이 기업의 요구에 대한 전술적(그리고 원초적인) 대응입니까?

장기적 솔루션은 모든 스크립트에 일반 텍스트 자격 증명을 포함해서는 안 되며, 그럴 수도 없습니다 . 명백한 보안 위험 외에도 발생하는 기술적 부채도 생각해 보세요. 자격 증명을 변경해야 하는 경우 모든 곳에서 자격 증명을 변경해야 합니다. 이를 추적하려면 시간과 노력이 필요합니다. 시간과 노력이 별로 없을 겁니다. 그렇지 않다면 처음부터 자동화를 도입해 시간을 벌려고 하지도 않을 테니까요.

따라서 보안 규칙 1을 위반하지 마십시오. 그보다 더 안전하고 현명하게 행동하세요. 자동화는 규모와 속도 요구 사항에 대한 전술적 대응이어서는 안 됩니다. 이는 전략적이어야 하며 실제로 그렇습니다. 즉, 이를 구현하는 방법의 장기적 결과에 더 주의를 기울이는 것을 의미합니다.