빠른 요약

  • ID 보안의 중심이 정기적인 권한 검토에서 지속적 검색, 중앙화된 보고, 행동 기반 탐지로 이동하고 있다. AWS, Wiz, Qualys의 자료는 접근 권한 거버넌스와 ID 소스 마이그레이션, 공격 탐지를 하나의 수명주기로 관리해야 한다는 흐름을 보여준다.
  • 엔지니어링 조직은 어떤 사용자와 기기가 접근 권한을 가졌는지뿐 아니라 권한의 출처와 정상으로 보이는 ID의 이상 행동까지 확인할 수 있어야 한다.
  • 현재 ID와 접근 권한의 관계를 매핑하고, 하나의 AWS 조직 단위나 사용자 그룹에서 지속적 검색을 시험한 뒤 과거 텔레메트리로 행동 규칙을 검증하라.

무슨 일이 있었나

ID 보안은 입사 시 권한을 부여하고 퇴사 시 회수하는 절차만으로 충분하지 않다. 여러 클라우드 계정과 애플리케이션, 디렉터리, 기기가 연결된 환경에서는 접근 상태가 계속 바뀌기 때문에 오늘 정확한 인벤토리도 곧 오래된 정보가 될 수 있다.

AWS, Wiz, Qualys가 공개한 자료는 공통적으로 지속적 ID 거버넌스와 행동 기반 탐지를 함께 다루는 방향을 제시한다. 특정 제품 하나를 도입하는 문제라기보다 어떤 ID가 존재하고 어디에 접근할 수 있으며, 어떤 활동이 정상 기준에서 벗어났는지 계속 확인하는 운영 모델에 가깝다.

정기적인 접근 권한 검토만으로 부족한 이유는 무엇인가?

분기 또는 연간 권한 검토는 컴플라이언스에 필요하지만 검토 사이에 감시 공백을 남긴다. 그동안 사용자의 역할이 바뀌거나 그룹에 권한이 추가될 수 있고, 새 계정이 만들어지거나 평범한 이름을 사용한 비인가 기기가 연결될 수도 있다.

AWS는 IAM Identity Center의 지속적 검색 및 보고 자동화를 통해 조직 확장에 따른 가시성 문제를 다룬다. IAM Identity Center는 외부 ID 공급자와 연동해 AWS Organizations 전반의 인증과 권한 부여를 중앙화할 수 있지만, 로그인 경로를 통합했다고 해서 모든 권한이 여전히 필요하거나 적절히 감시된다는 의미는 아니다.

따라서 거버넌스 계층은 어떤 ID와 그룹이 존재하는지, 어느 계정과 애플리케이션에 접근할 수 있는지, 이전 관찰 이후 무엇이 달라졌는지를 반복해서 확인해야 한다. 정기 보고서는 그대로 유지하되, 보고서의 기반 데이터는 감사 직전에 수작업으로 모으기보다 지속적으로 검색하는 편이 적절하다.

ID 소스 마이그레이션이 보안 변경인 이유는 무엇인가?

내장 ID 저장소에서 Active Directory나 외부 ID 공급자로 전환하면 사용자 식별자, 그룹 멤버십, 권한 매핑 방식이 달라질 수 있다. AWS의 IAM Identity Center ID 소스 전환 가이드는 Active Directory 마이그레이션 전략과 permission set 자동화를 다루며, 디렉터리 변경과 AWS 권한 모델을 함께 고려해야 함을 보여준다.

운영상 위험은 로그인 실패에 그치지 않는다. 사용자나 그룹 매핑이 어긋나면 업무에 필요한 권한이 사라지거나 이전 모델의 권한이 그대로 남을 수 있다. 전환 전 기준선을 저장하고, 현재 할당 관계를 기록하며, 제한된 범위에서 단계별로 결과를 대조하고, 복구 가능한 경계를 명확히 정해야 한다.

이는 관리형 자동화 Control Plane을 설계하는 방식과 비슷하다. 신뢰할 수 있는 상태 원본과 감사 추적, 승인 경로가 필요하다. 자동화는 반복 작업을 줄여 주지만, 의도한 접근 상태와 실제 상태의 차이를 탐지할 수 있을 때 비로소 보안 통제로 기능한다.

정상적으로 보이는 기기 이름을 신뢰하기 어려운 이유는?

Wiz는 공격자가 공개 도구의 식별 가능한 흔적을 남기는 대신 기업 환경에 자연스럽게 섞이는 기기 이름을 생성할 수 있다고 설명한다. 이에 따라 이름 규칙이나 의심스러운 문자열 목록에 주로 의존하는 Entra ID 탐지 규칙의 효용은 낮아질 수 있다.

행동 기반 탐지는 “이 객체의 이름은 무엇인가?”보다 “어떤 맥락에서 등장했고 이후 무엇을 했는가?”를 묻는다. 방어 조직은 기기 조인 맥락, 이벤트와 연결된 ID, 후속 활동의 순서, 평상시 행동과의 차이를 평가할 수 있다. 다만 이는 모든 조직에 통용되는 고정 지표가 아니라 분석 방향이며, 실제 임계값은 각 조직의 데이터로 검증해야 한다.

Qualys도 ETM Identity를 ID 기반 공격의 더 빠른 탐지와 연결해 소개한다. 그러나 제공된 자료에는 제품을 비교할 수 있는 벤치마크나 충분한 구현 세부 정보가 없다. 따라서 속도에 관한 표현을 독립적으로 검증된 결과로 받아들이기보다 자체 텔레메트리와 공격 시나리오로 탐지 범위와 조사 시간을 확인해야 한다.

엔지니어링·보안팀은 무엇부터 적용해야 하는가?

우선 ID 소스, 사용자, 그룹, permission set, 계정, 애플리케이션과 할당 관계를 조회 가능한 기준선으로 만들어야 한다. 각 레코드에 책임자와 관찰 시점을 포함해야 현재 접근 권한과 오래된 인벤토리를 구분할 수 있다.

  1. 검색: 환경의 변화 속도에 맞는 주기로 ID와 접근 관계를 자동 수집한다.
  2. 대조: 관찰한 상태를 의도한 정책과 비교하고, 책임자나 현재 업무 목적이 불명확한 권한을 우선 처리한다.
  3. 변경 상관분석: 사용자 생성, 그룹 변경, 권한 할당, 기기 조인 이벤트를 하나의 타임라인에서 분석한다.
  4. 행동 규칙 검증: 과거 데이터로 규칙을 재생하고 오탐을 측정한 뒤, 신뢰도가 높은 상황에만 자동 차단을 적용한다.
  5. 마이그레이션 리허설: 제한된 사용자로 새 ID 소스를 시험하고 전환 전후 권한과 롤백 절차를 확인한다.

접근 변경을 관찰하는 데 걸린 시간, 책임자가 지정된 권한의 비율, 미해결 드리프트, ID 경보 조사 시간 등을 내부 운영 지표로 사용할 수 있다. 이는 인용된 업체가 발표한 지표가 아니라 실무 권고이며, 목표치는 조직의 위험 수준과 인력에 맞춰 정해야 한다.

업무 영향을 크게 주는 대응에는 사람의 검토도 남겨 두는 편이 안전하다. 사용자 비활성화나 기기 격리는 공격을 제한할 수 있지만, 정확도가 낮은 규칙은 정상적인 운영도 즉시 중단시킬 수 있다. 정보 보강, 알림, 승인, 차단 순서로 대응을 단계화하면 근거의 품질이 높아질수록 자동화 범위를 넓힐 수 있다.

결론

  • 정기 검토를 지속적 ID 검색과 보고로 보완해야 한다.
  • ID 소스 전환에서는 로그인뿐 아니라 사용자, 그룹, 권한을 모두 대조해야 한다.
  • 그럴듯한 기기 이름은 신뢰의 근거가 아니며 맥락과 행동이 더 강한 신호다.
  • 계정 비활성화나 기기 격리를 자동화하기 전에 자체 데이터로 탐지 규칙을 검증해야 한다.

관련 글

참고 자료

개발자가 주목해야 하는 이유

엔지니어링 조직은 어떤 사용자와 기기가 접근 권한을 가졌는지뿐 아니라 권한의 출처와 정상으로 보이는 ID의 이상 행동까지 확인할 수 있어야 한다.

  1. 1현재 ID와 접근 권한의 관계를 매핑하고, 하나의 AWS 조직 단위나 사용자 그룹에서 지속적 검색을 시험한 뒤 과거 텔레메트리로 행동 규칙을 검증하라.