다른 쪽에서 온 파견: 스크립트에서 소프트웨어까지

Source: Dev.to

Introduction

보안 엔지니어로 커리어를 시작할 때, 나는 보안 운영 센터(SOC) 내 웹 게이트웨이용 허용 목록 관리 시스템을 구축했습니다. 단순한 스크립트를 넘어, 핵심 보안 구성 요소가 의존하는 실시간 시스템이 되었습니다. /32 대신 /3 IP 범위를 차단하는 작은 실수 하나로 40,000명 직원 전체가 인터넷의 3분의 1에 접근할 수 없게 되었습니다. 이 사건은 내가 만든 시스템이 이런 치명적인 오류를 방지해야 한다는 점을 명확히 보여주었습니다.

SOC 분석가 매니저, 내 매니저, 그리고 나 사이의 정기적인 논의를 통해 내 코드가 다른 사람들의 업무에 미치는 영향을 깨달았습니다. 자동화가 아니라 소프트웨어 자체에 대해 책임을 느낀 첫 순간이었습니다.

Crossing Over: From Security to Platform Engineering

이 시리즈에서는 보안 엔지니어링에서 플랫폼 엔지니어링으로 전환하면서 배운 교훈을 다룹니다. 과거의 나에게 전하고 싶은 이야기와 현재 소프트웨어·플랫폼 엔지니어의 관점으로 문제를 해결하는 방식을 공유합니다.

• 보안 실무자에게: 다른 쪽에서 볼 수 있는 모습을 엿볼 수 있습니다.
• 보안 팀과 협업하는 개발자에게: 우리가 왜 그런 식으로 생각하는지에 대한 통찰을 제공합니다.

Managing Growing Vulnerabilities

보안 조직에 있을 때, 나는 취약점 수가 우리가 해결할 수 있는 속도보다 더 빨리 증가한다는 것을 발견했습니다. 빈번한 패치 작업을 해도 말이죠. 클라우드 플랫폼이 등장하면서 잘못된 구성으로 인한 발견도 늘어났습니다. 같은 결과를 반복하지 않기 위해 접근 방식을 바꾸었습니다.

Preventative Platform Controls

추가적인 발견을 만들기보다, 모든 이해관계자가 받아들일 수 있는 플랫폼 제어를 식별했습니다. 공개 S3 버킷은 데이터 유출의 흔한 원인이었으므로, 공개 버킷을 전면 차단하는 예방 제어를 구현했습니다. 이를 통해 개발 팀과 취약점 관리 팀 모두에게 해당 유형의 문제가 사라졌습니다.

Collaboration and Rollbacks

보안 팀이 기업 내 모든 시스템을 소유·운영하는 것은 아닙니다. 하지만 50~100개의 팀이 아니라 하나의 플랫폼·인프라 팀과 협업하면 복구 시간이 크게 단축됩니다. 가끔은 제어가 팀의 시스템 운영에 부정적인 영향을 미쳐 롤백해야 할 때도 있었습니다.

• Lesson: 점진적인 롤아웃은 소프트웨어 엔지니어링에서 이미 일반적인 실천이며, 필수적입니다.
• Policy‑as‑Code: 몇 분 만에 이전 정책 버전으로 되돌릴 수 있게 해줍니다.

Transferable Skillsets

많은 보안 스킬이 예상보다 더 이식성이 높았습니다:

• Security reviews는 시스템 설계 논의와 운영 트러블슈팅에 대비하게 해주었습니다.
• Incident response 경험—공격자의 흔적을 추적하는 것—은 로그와 트레이스를 연결해 실시간 시스템을 디버깅하는 데 큰 도움이 되었습니다.

Building Effective Controls

내가 만든 가장 효과적인 제어는 개발 팀의 작업 방식을 이해하고 마찰 없이 위험을 제거하는 방법에서 비롯되었습니다. 모든 사람이 소프트웨어 엔지니어가 될 필요는 없지만, 핵심 개념과 작업 방식을 파악하면 팀의 속도를 늦추지 않는 솔루션을 만들 수 있습니다.

Next Topic

다음 포스트에서는 CI/CD와 효과적인 제어, 기본값, 예외 사이의 균형을 어떻게 맞출지 살펴보겠습니다.