Microsoft 365 테넌트는 클라우드 인프라다. Entra ID, Exchange Online, SharePoint, Teams에 걸친 수백 개의 보안 관련 설정이 있고, 이 설정들은 관리되지 않는 AWS 계정과 똑같이 드리프트한다. 관리자가 장애 대응 중에 설정 하나를 바꾸고 되돌리지 않는다. Microsoft가 서비스 업데이트로 기본값을 바꾼다. 두 분기 전에 끝난 파일럿 때문에 외부 업체가 여전히 게스트 접근 권한을 갖고 있다. 아무도 이것을 검토하지 않는다. 테넌트는 "IT의 일"이지 "인프라의 일"이 아니라고 여겨지기 때문이다. 포스처 스캐닝은 지루하지만 효과적인 해법이다: 테넌트의 실제 구성을 공개된 보안 베이스라인과 지속적으로 비교하고 격차를 보고한다. 그리고 2026년에 그 스캐너를 돌리는 현실적인 방법은 SaaS다. 즉 클라우드로 클라우드를 점검하는 셈이다. 이 글은 그 101이며, Aether365를 예시로 사용한다. 미리 밝혀두면 Aether365는 내 제품이다.

시작 전에 한 가지 원칙: read-only가 기본값이다. 별도의 명시적 동의 없이는 어떤 것도 테넌트에 쓰기 권한을 얻지 못한다.

테넌트를 프로덕션 계정처럼 다뤄라

누군가 구성 감사도, 드리프트 탐지도, 변경 이력도 없이 프로덕션 AWS를 운영한다면 태만이라고 부를 것이다. 대부분의 조직이 Microsoft 365를 정확히 그렇게 운영한다. 그 안에 ID 공급자, 모든 이메일, 대부분의 파일이 들어 있는데도 말이다. 테넌트는 당신이 운영하는 다른 모든 것의 ID 평면이다. 그곳의 Conditional Access 설정 오류 하나는 공격자에게 공개된 S3 버킷보다 더 값지다.

인프라 사고방식은 그대로 옮겨진다. 필요한 것은 선언된 베이스라인, 현실과 베이스라인의 정기적인 비교, 그리고 둘이 어긋날 때의 알림이다. AWS 세계라면 Config 규칙이나 Security Hub 표준을 집어들 것이다. Microsoft 365에서 그에 해당하는 것이 포스처 벤치마크다.

알아둘 가치가 있는 세 가지 벤치마크

세 가지 베이스라인이 중요한 것 대부분을 커버하고, 진지한 스캐너라면 최소한 그중 하나에는 매핑된다:

  • CIS Microsoft 365 Foundations Benchmark: 가장 폭넓은 벤치마크. MFA 강제부터 메일박스 감사, 공유 정책까지 스위트 전체에 걸친 800개 이상의 점검 항목. "무엇을 기준으로 감사했는가?"에 대한 기본 답변이다.
  • EIDSCA(Entra ID Security Configuration Analyzer): 전적으로 Entra ID에 집중한다. 누가 인증하고, 동의하고, 애플리케이션을 등록할 수 있는지 결정하는 설정들이다. 표면은 작지만 폭발 반경은 가장 크다.
  • CISA ScuBA(Secure Cloud Business Applications): 미국 연방 정부의 M365 베이스라인. 더 엄격하고 더 단정적이다. 정부 밖에서도 "공략하기 어려운 대상이라면 어떻게 할까"의 참조 기준으로 유용하다.

벤치마크들은 서로 겹치는데, 그것은 괜찮다. ID 컨트롤에서의 겹침은 합의가 어디에 있는지 알려주고, 합의된 발견 항목이 가장 먼저 고칠 것들이다.

스크립트냐 SaaS냐: 진짜 트레이드오프

이 점검들은 얼마든지 직접 돌릴 수 있다. Graph API가 바로 거기 있고, Maester 같은 커뮤니티 도구가 상당 부분을 감싸주며, 테넌트 하나를 대상으로 한 예약 PowerShell 실행은 주말 프로젝트 수준이다. 점검 항목들이 실제로 무엇을 하는지 배우는 데는 이 접근을 좋아한다.

이 방식은 세 가지 축에서 확장이 멈춘다. 유지보수: 벤치마크는 버전이 올라가고, Graph 엔드포인트는 바뀌며, 스크립트 모음은 조용히 당신이 소유한 제품이 된다. 이력: 특정 시점의 스크립트는 오늘의 상태를 알려주지만, 포스처 질문은 추세 질문이다. 이 컨트롤이 언제 퇴행했고 그 주변에서 무엇이 바뀌었는가. 테넌시: 테넌트를 하나 이상 관리하는 순간, 예를 들어 고객이 서른 곳인 MSP라면, 테넌트별 스크립트와 자격 증명 자체가 리스크가 된다.

SaaS 스캐너는 이 거래를 뒤집는다: 읽기 전용 Microsoft Graph 동의를 부여하면, 매일, 매주, 또는 매월 일정에 따라 컴플라이언스 스캔과 노출 스캔을 실행하고 이력을 보관해 준다. 꼼꼼히 따져야 할 부분은 동의 모델이다. 외부 서비스를 당신의 ID 평면에 연결하는 일이기 때문이다. 읽기 전용이 기본값이어야 하고, 그 이상은 거절할 수 있는 별도의 명시적 동의여야 한다. 이 하나의 속성이 규제 대상 EU 테넌트에게 클라우드로 클라우드를 점검하는 방식을 받아들일 만하게 만든다.

Aether365가 커버하는 것

Aether365는 그 스캐너에 대한 내 해석이다. 핵심은 위의 세 벤치마크 모두에 대한 컴플라이언스 스캐닝과 노출 스캐닝이며, 테넌트별로 스케줄링되고, MSP를 위한 멀티 테넌트 관리, Teams와 이메일 알림, 그리고 AI 어시스턴트가 스캔 결과를 조회하게 하고 싶을 때를 위한 REST API와 내장 MCP 서버를 갖추고 있다. EU 기반이고 GDPR을 준수하며, 가입 시 데이터 리전을 직접 선택하고, 스캔 데이터는 어떤 모델의 학습에도 사용되지 않는다.

두 가지 기능은 테넌트의 내부 시점을 넘어선다. External Attack Surface는 테넌트가 외부에 무엇을 노출하는지 바깥에서 안쪽으로 점검한다: M365 메일의 하중을 받치는 SPF, DKIM, DMARC 레코드, 90일 사전 경고가 붙은 인증서 만료, 방치된 DNS와 서브도메인 탈취 리스크, 열린 채 남아 있는 레거시 인증 엔드포인트, 그리고 공개된 SharePoint와 OneDrive 공유. 그리고 옵트인 방식이며 Pro와 Enterprise 전용인 AI Pilot은 발견 항목을 구체적인 Microsoft Graph 수정안으로 바꾸고, 어떤 것도 적용되기 전에 항목별로 승인을 받으며, 검증된 감사 기록을 남긴다. 읽기 전용이 여전히 기본값이다. 쓰기 경로는 원할 때만 활성화하는 별도의 Microsoft 동의다. 테넌트 하나에 월간 스캔을 제공하는 Free 요금제가 있는데, 첫 CIS 점수를 보기에는 충분하고, 보통 그 첫 점수가 동기가 된다.

핵심 정리

101은 단순하다: Microsoft 365 테넌트는 클라우드 계정과 같은 수준의 포스처 규율을 받을 자격이 있고, 측정 기준이 될 벤치마크는 이미 존재하며, 운영상의 질문은 스캐너를 직접 돌릴지, 아니면 SaaS에 읽기 전용 동의를 주고 일정에 따라 돌리게 할지뿐이다. 스크립트는 컨트롤을 가르쳐 주고, 서비스는 시간이 지나도 당신을 정직하게 유지해 준다. 어느 쪽이든 피해야 할 실패 모드는 지금의 기본값, 즉 아무도 점검하지 않는 상태다.

다음으로 읽을 글

같은 플랫폼의 AI 측면, 즉 조치에 승인 게이트가 필요한 이유와 AI 생성 리포트의 실제 용도가 궁금하다면 ercan.ai의 M365 Security 101: AI Pilot과 Business Impact Reports를 참고하라. 클라우드, 보안 포스처, 플랫폼 작업에 대한 컨설팅 문의, 또는 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.