Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI가 공격 도구로 사용되면서 보안 위협의 속도가 급격히 빨라지고 있습니다. 본문은 웹 서비스 운영자가 당장 착수해야 할 보안 대책과 사고방식을 제시하며, NIST CSF 2.0 프레임워크를 활용하여 '파악(Identify)', '방어(Protect)', '탐지(Detect)'에 집중할 것을 권고합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기2026년 9월, Timescar의 웹 시스템에 대한 무단 접근으로 약 660만 계정 정보가 유출된 것이 공표되었다. 이후 약 160만 계정에 대해서는 운전면허증 이미지 등의 본인 확인 서류도 유출했던 것으로 밝혀졌다.
또한, JPCERT/CC 역시 국내 조직에서 정보 유출이 연이어 발생하고 있다는 것에 대해 주의 환기를 하고 있으며, 일반 이용자 대상 서비스뿐만 아니라 BI 툴이나 직원을 위한 관리 시스템에서도 정보가 유출되는 사례가 보고되고 있다.
이러한 뉴스를 접하고 자사의 시스템은 괜찮을지, 무언가를 놓치고 있지는 않은지 불안해하는 담당자가 많을 것이다.
하지만 보안 대책으로 생각할 수 있는 모든 것을 나열한다면 끝이 없고, 그 모든 것이 완료될 때까지 안심할 수 없다면 담당자는 언제까지나 편히 잠들 수 없을 것이다.
그렇다면 웹 서비스를 운영하는 회사의 보안 담당자나 엔지니어는 무엇부터 착수하고 어디까지 대응해야 일단 안심할 수 있을까?
이 글에서는 제가 진행했던 경험을 녹여내면서 그 사고방식을 정리하고자 한다.
구체적인 예시로는 AWS 등이 등장하지만, 기본이 되는 생각은 소규모 조직이든 온프레미스 시스템을 운영하는 조직이든 공통적이다.
생성 AI가 공격에 사용되고 있다는 것은 이미 구체적인 사례로 확인되었다.
예를 들어, CrowdStrike는 2026년 9월 하순부터 10월 상순까지 한국 금융기관을 노린 공격에 대해, 공격자 측 서버에 남겨진 기록을 통해 중국에서 개발된 오픈소스 침투 테스트 도구인 'ARTEX'와 여러 LLM이 사용되었음을 보고했다.
또한, 공격의 속도 면에서도 주의해야 할 변화가 있다.
Palo Alto Networks의 2026년판 Unit 42 인시던트 대응 리포트에 따르면, 회사가 조사한 사례에서 침입부터 데이터 절취 확인까지 걸리는 시간은 빠른 쪽을 기준으로 나눈 값으로, 2024년의 285분에서 2025년의 72분으로 단축되었다.
공격자가 조사나 코드 작성, 시행착오에 AI를 이용할 수 있게 된 이상, 방어 측에서는 설정 누락이나 알려진 취약점을 방치할 시간이 극도로 짧아지고 있다고 생각해야 할 것이다.
한편, 중요한 것은 당장 대처할 수 있는 문제도 구체적으로 보이고 있다는 점이다.
2026년 4월경에는 Claude Mythos와 같은 고성능 LLM이 미지의 취약점을 발견하는 능력과 그 위험성이 주목받았지만, 앞서 언급된 JPCERT/CC의 주의 환기에서는 알려진 취약점 탐색, 환경 설정 파일이나 백업 파일 절취, API에 대한 부정 조작 등이 거론되었다.
미지의 공격에 대비할 필요가 있는 한편, 알려진 약점이나 관리 미비점을 점검하는 의미도 충분하며, 불필요한 공개를 닫고, 인증을 강화하고, 오래된 소프트웨어를 업데이트하고, 중요한 조작을 감시하는 등 당장 착수할 수 있는 대책이 있다.
구체적인 대책을 시작하기 전에, 먼저 무엇을 '보안 대책 초기 정비가 완료된 상태'로 할지 이미지를 갖는 것이 중요하다.
이 정리에는 미국 국립표준기술연구소(NIST)가 공개한 Cybersecurity Framework가 도움이 될 것이다.
NIST CSF 2.0은 보안 관련 활동을 Govern (통치), Identify (파악), Protect (방어), Detect (탐지), Respond (대응), Recover (복구)의 여섯 가지 기능으로 정리하는 프레임워크이다.
평상시 초기 정비를 진행하는 담당자라면, '통치'의 실천으로서 필요한 권한과 승인을 얻은 후, 먼저 '파악', '방어', '탐지' 세 가지에 주목하여 다음과 같이 '목표 상태'를 구체화하면 좋을 것이다.
이것은 NIST가 정한 합격 기준이 아니라, 그 프레임워크를 사용하여 이 글에서 생각하는 초기 정비의 도달점을 정리한 것이다.
이 표에서 특히 의식해야 할 것은 대책을 설정했다는 것이 아니라, 의도한 대로 기능하고 있다는 것을 도달점으로 삼고 있다는 점이다.
예를 들어, 방어로서 MFA를 '사용해 달라고 요청한' 상태와 '대상자 전원에게 강제되는' 상태는 다르며, 탐지 역시 '로그가 저장되어 있는' 상태와 '문제가 발생했을 때 담당자가 알아차릴 수 있는' 상태는 다르다.
또한, 방어하지 못한 부분을 파악만 해서는 그 위험이 줄지 않는다. 즉시 수정할 수 없다면 공개 범위를 좁히는 등의 임시 대책을 취하고, 그래도 남는 위험에 대해서 책임자가 판단할 수 있도록 해야 한다.
물론, 인지한 후의 대응도 필요하다. 누가 계정을 정지시키고, 누가 시스템을 격리하며, 누구에게 연락할지를 결정해 두는 것과, 필요한 데이터를 백업에서 복원할 수 있는지 확인하는 것은 '대응(Respond)' 및 '복구(Recover)'의 최소한의 준비로 갖춰두어야 한다.
여기까지 정리되면, '아직 무언가 있을지도 모른다'라며 끝없이 찾고 있는 상태에서 벗어나, 남아있는 리스크와 다음에 다룰 것을 파악하면서 지속적으로 운영하는 상태로 전환할 수 있다.
내가 생각하는 '일단 안심할 수 있는' 상태는 바로 이 상태이다.
목표가 정해졌다면, 다음으로는 대책을 '효과의 크기'와 '도입 및 운영에 필요한 노력(手間)'이라는 두 축으로 정리하는 의사결정 매트릭스(Decision Matrix)를 사용하면 판단하기 쉽다.
NIST의 프레임워크로 전체적인 대책을 정리하고, 매트릭스로 개별 대책의 실행 순서를 결정하는 식으로 활용하는 것이다.
예를 들어, 아래 그림은 나의 사례에서 보안 대책을 의사결정 매트릭스에 옮겨 놓은 것이다.
여기서 말하는 효과는 지키고자 하는 자산의 중요성, 외부로부터 도달하기 쉬운 정도, 악용될 가능성, 피해의 크기를 고려하여 얼마나 리스크를 줄일 수 있는가를 의미한다. 노력에는 구현 시간뿐만 아니라 동작 확인이나 이전(移行), 그 이후의 모니터링 및 운영까지 포함된다.
같은 대책이라도 조직이나 시스템에 따라 놓이는 위치는 달라진다. 이미 인증 기반이 통일된 회사라면 MFA 강제화가 짧은 시간에 끝날 수도 있지만, 오래된 시스템이 많이 남아 있다면 이전을 수반하는 큰 작업이 된다.
또한, 실제로 악용되고 있는 취약점이나 고객 데이터가 외부에서 가져갈 수 있는 문제가 발견된 경우에는 긴급 대응을 우선한다. 이는 '당장 할 수 있는 것'만 계속 처리하다가 큰 리스크를 남기지 않도록 하는 매트릭스이기도 하다.
우선, 짧은 시간 안에 큰 리스크를 줄일 수 있는 것부터 착수한다.
특히, 외부에 공개할 필요가 없는 기능이나 포트를 닫고 접근 가능한 사용자나 경로를 제한하는 것은 '공격 대상 영역 축소(Attack Surface Reduction)'라고 불리는 생각이다. 클라우드든 온프레미스든, 가장 먼저 확인하고 싶은 항목이 된다.
나 역시 전 직원 MFA 강제화, GuardDuty 활성화, 관리 화면이나 BI 툴 접근을 Slack으로 전달하는 것부터 시작했다. 중요한 화면에 대한 접근이 평소 눈에 보이게 되면, 누가 무엇을 하고 있는지 파악할 수 있는 발판이 된다.
AWS의 인증 및 권한 관리에 대해서는 IAM(Identity and Access Management)의 보안 모범 사례에 MFA, 최소 권한 원칙(Least Privilege), 불필요한 인증 정보 삭제 등이 정리되어 있다.
다음으로, 구성 변경이나 이전, 충분한 동작 확인이 필요하더라도 큰 리스크를 줄일 수 있는 것에 착수한다.
네트워크를 분리하여 한 곳에 침입하는 것이 다른 시스템으로 퍼지기 어렵게 한다. - 개인 정보를 다루는 API 등의 인가 처리(Authorization)를 검토하고 접근 제어를 검증한다.
예를 들어 AWS에서는 AWS 위에서 동작하는 처리에는 IAM 역할을 사용하고, GitHub Actions와 같은 외부 실행 환경에서는 OIDC(OpenID Connect)를 이용하여 임시 인증 정보를 얻는 방법이 있다. 목표는 장기간 계속 사용하는 비밀 키를 여러 곳에 저장할 필요가 없는 상태이다.
데이터베이스 암호화에 대해서는 무엇으로부터 보호하기 위한 것인지를 이해한 후 우선순위를 판단해야 할 것이다. Amazon RDS의 저장 시 암호화(Encryption at Rest)는 스토리지나 백업 등의 보호에 도움이 되지만, 그것만으로 정규 접근 권한을 빼앗겨 데이터를 읽어 나가는 것을 막을 수는 없다. 인증 및 접근 제어 문제도 함께 대처할 필요가 있다.
이 구분의 대책은 완료까지 시간이 걸리기 때문에, 담당자와 기한을 정하여 일찍 착수하고, 그 사이에 필요한 임시 대책을 실시해 두어야 한다.
마지막으로, 개별적인 효과는 작더라도 단시간에 실행할 수 있고 운영을 돕는 대책이 있다.
여기서는 기본적인 대장 관리와 모니터링이 있다는 전제하에, 이를 더 사용하기 쉽게 만드는 개선 사항을 제시하고 있다.
만약 연락처가 전혀 정해지지 않아 그 부족함 때문에 대응 자체가 멈춰버리는 상태라면, 당연히 우선순위는 높아진다.
이러한 개선들은 쌓여나가면 도움이 되지만, 작업하기 쉽다고 해서 중대한 취약점 수정이나 접근 제어 재검토를 미루어서는 안 된다.
'탐지(検知)'에 대해서도 제품을 도입하는 것과 이상 징후를 감지하는 것은 분리해서 생각할 필요가 있다.
예를 들어 AWS의 경우, AWS Config는 리소스 구성을 기록하고 변화를 파악하는 데 사용하며, Amazon GuardDuty는 의심스러운 활동이나 위협 탐지에 사용한다. 또한, IAM 사용자 생성이나 권한 변경 등 지정된 작업을 알리고 싶을 때는 CloudTrail 이벤트를 EventBridge로 가져와서 알림을 보내는 구성이 활용될 수 있다.
AWS에 의한 IAM 설정 변경 알림 절차에는 설정 예시와 알림 테스트 방법이 정리되어 있다.
애플리케이션 측면에서도 중요한 관리 화면 로그인, 권한 변경, 대량 데이터 출력 등 자사 시스템에서 놓치고 싶지 않은 작업을 정의하고 기록 및 알림을 보내야 한다.
저는 이번 대규모 유출 사건을 계기로 AWS 측 설정 변경과 직원만 사용하는 관리 콘솔 접근은 Slack으로 알리도록 결정했다.
다만, 알림이 늘어나면 읽어내지 못하게 되므로, 알림하는 내용의 범위를 줄여야 한다. 최종적으로는 예상한 작업을 실행했을 때 알림이 도착하고, 그것을 누가 확인할지까지 결정된 상태를 목표로 해야 할 것이다.
현대에는 AI가 방어 측면에서도 필수적인 도구다.
자산 목록 조사라면, 사내 채팅이나 문서는 알려지지 않았던 서비스를 찾는 단서가 될 수 있다.
코드나 설정 조사를 할 때도
