ID 관리

ID 관리는 사용자, 애플리케이션, 서비스)가 어떤 조건에서 어떤 리소스에 액세스할 수 있는지를 제어하여 클라우드 보안의 기반을 설정합니다. 네트워크 경계 및 정적 자격 증명을 사용하는 기존의 경계 기반 보안과 달리, 최신 클라우드 환경에서는 분산된 다중 테넌트 아키텍처에서 동적 ID 확인, 지속적인 인증 및 컨텍스트 인식 액세스 결정을 요구합니다. 포괄적인 ID 거버넌스를 구현하는 조직은 자격 증명 기반 공격, 무단 액세스 및 권한 에스컬레이션을 방지하는 반면, ID 제어를 소홀히 하는 조직은 계정 손상, 횡적 이동 및 취약한 인증 또는 과도한 권한을 악용하는 지속적인 위협에 직면합니다.

ID 관리 보안 도메인의 네 가지 핵심 핵심 요소는 다음과 같습니다.

사용자의 ID를 보호합니다. 중앙 집중식 ID 관리, 강력한 다단계 인증, 완전한 수명 주기 관리 및 PAW(권한 있는 액세스 워크스테이션) 및 비상 액세스(중단) 계정을 비롯한 보안 액세스 방법을 통해 모든 사용자 계정, 특히 권한 있는 사용자의 보안을 설정하고 유지 관리합니다.

관련 컨트롤:

• IM-1: 중앙 집중식 ID 및 인증 시스템 사용
• IM-2: ID 및 인증 시스템 보호
• IM-5: 애플리케이션 액세스에 SSO(Single Sign-On) 사용
• IM-6: 강력한 인증 컨트롤 사용
• IM-7: 조건에 따라 리소스 액세스 제한

애플리케이션 및 비밀 보호: 자동화된 ID 관리, 적절한 서버 및 서비스 인증 및 보안 비밀 관리를 통해 비인간 ID(애플리케이션, 서비스)를 안전하게 관리하여 자격 증명 노출을 방지합니다.

관련 컨트롤:

• IM-3: 애플리케이션 ID를 안전하고 자동으로 관리
• IM-4: 서버 및 서비스 인증
• IM-8: 자격 증명 및 비밀 노출 제한

보안 액세스: ID가 최소 권한 원칙을 통해 적절한 리소스 액세스 권한을 갖도록 하고, 상주 권한을 피하고, 실시간 위험 평가를 기반으로 컨텍스트 인식 액세스 제어를 활용합니다.

관련 컨트롤:

• IM-7: 조건에 따라 리소스 액세스 제한

IM-1: 격리를 보장하면서 ID 및 인증 중앙 집중화

Azure Policy:Azure 기본 제공 정책 정의인 IM-1을 참조하세요.

보안 원칙

중앙 집중식 ID 및 인증 시스템을 사용하여 클라우드 및 비 클라우드 리소스에 대한 조직의 ID 및 인증을 제어합니다.

ID 및 인증을 중앙 집중화하는 동안 엔터프라이즈 차원의 전략에 따라 ID를 분리하고 격리해야 합니다. 목표는 일상적인 액세스에 사용되는 자격 증명 및 ID와는 별도로, 프로덕션 환경을 관리하는 것입니다. 엔터프라이즈 차원의 전략에 따라 ID 분리 및 격리는 다음을 포함할 수 있습니다.

• ID에 대한 최소 권한 액세스 적용
• 관리 ID 및 비관리 ID 분리
• 환경 간 아이덴티티 분리
• 워크로드 ID 분리 구현
• 테넌트 간에 ID 경계 분리 적용

완화할 리스크

• 권한 없는 액세스: 분산 또는 로컬 인증 시스템은 종종 일관되지 않은 보안 정책, 약한 암호 관행 또는 모니터링되지 않는 계정으로 이어지게 되므로 공격자가 잘못 구성되거나 오래된 자격 증명을 악용하여 중요한 리소스(예: 무차별 암호 대입 또는 도난된 자격 증명을 통해)에 액세스할 수 있습니다.
• 자격 증명 도난 및 재사용: 조각화된 ID 시스템은 자격 증명이 안전하지 않게 저장되거나(예: 일반 텍스트 또는 약한 해시로) 시스템 간에 재사용될 위험을 증가시키고 공격자가 손상된 한 시스템에서 자격 증명을 수집하여 다른 곳에서 사용할 수 있게 합니다(예: 피싱 또는 자격 증명 덤프를 통해).
• 일관성 없는 액세스 제어: 중앙 집중식 거버넌스가 없으면 서로 다른 시스템에는 다양한 액세스 정책이 있을 수 있으며, 이로 인해 공격자가 권한을 확대하거나 권한 없는 리소스에 액세스하기 위해 악용할 수 있는 권한이 있는 계정 또는 분리된 계정이 발생할 수 있습니다.
• 가시성 및 모니터링 부족: 탈중앙화 인증에는 통합 로깅 및 모니터링이 없기 때문에 무단 로그인 시도 또는 비정상적인 사용자 동작과 같은 의심스러운 활동을 감지하기가 어려우므로 검색되지 않은 위반의 위험이 증가합니다.

MITRE ATT&CK

• 초기 액세스(TA0001): 기본 자격 증명 또는 오래된 프로토콜이 있는 로컬 계정과 같이 약하거나 탈중앙화된 인증 메커니즘을 악용하여 공격자가 무단 입력(예: T1078 - 유효한 계정)을 얻을 수 있습니다.
• 자격 증명 액세스(TA0006): 조각화된 ID 시스템에서 자격 증명 도난, 안전하지 않은 스토리지(예: 로컬 시스템의 일반 텍스트 암호) 또는 약한 인증 방법 악용, 자격 증명 덤프 또는 재사용 촉진(예: T1003 - OS 자격 증명 덤프).
• 권한 상승(TA0004): 중앙 집중화되지 않은 시스템의 일관되지 않은 액세스 제어를 활용하여 권한이 초과되거나 분리된 계정을 악용하여 공격자가 중요한 리소스(예: T1078 - 유효한 계정)에 대한 액세스 권한을 높일 수 있습니다.
• 방어 회피(TA0005): 중앙 집중식 모니터링 부족으로 인한 탐지를 우회하여 공격자가 경고를 트리거하지 않고 무단 작업을 수행할 수 있도록 합니다(예: T1562 - 방어 손상).

IM-1.1: ID 및 인증 중앙 집중화

중앙 집중식 ID 관리는 모든 리소스에서 일관된 정책 적용, 통합 모니터링 및 간소화된 액세스 제어를 제공하여 조각화된 인증 시스템의 보안 위험을 제거합니다. 최신 클라우드 환경에는 강력한 인증 방법, 조건부 액세스 정책 및 포괄적인 감사 로깅을 지원하는 단일 신뢰할 수 있는 ID 원본이 필요합니다. 중앙 집중식 ID 시스템을 채택하는 조직은 하이브리드 및 다중 클라우드 아키텍처에 대한 유연성을 유지하면서 자격 증명 확산을 줄이고, 보안 태세 가시성을 개선하고, 규정 준수를 간소화합니다.

다음 방법을 사용하여 중앙 집중식 ID 관리를 구현합니다.

• 클라우드 ID 플랫폼 채택: Microsoft Entra ID는 엔트라 ID를 지원하는 Microsoft 및 타사 환경에 대한 인증, 권한 부여 및 거버넌스를 중앙 집중화하는 다중 테넌트 클라우드 기반 ID 및 액세스 관리 서비스입니다. Microsoft Entra ID를 표준화하여 모든 리소스에서 ID를 관리하십시오.

• 클라우드 리소스 ID 관리: Azure Storage, Azure Virtual Machines(Linux 및 Windows), Azure Key Vault, PaaS 및 SaaS 애플리케이션을 비롯한 Microsoft 클라우드 리소스에 대한 관리 ID 및 워크로드 ID 페더레이션을 사용하여 비밀을 제거하고 격리를 보장합니다.

• 조직 리소스 인증 중앙 집중화: Azure에서 호스트되는 애플리케이션, 회사 네트워크의 타사 애플리케이션 및 타사 SaaS 애플리케이션과 같은 조직 리소스에 SSO(Single Sign-On) 및 조건부 액세스를 활용하여 안전한 컨텍스트 인식 액세스를 제공합니다.

• 하이브리드 ID 동기화: 엔터프라이즈 ID에 대한 일관되고 중앙에서 관리되는 하이브리드 ID 전략을 유지하려면 Microsoft Entra Connect 동기화 를 통해 온-프레미스 Active Directory를 Microsoft Entra ID와 동기화합니다.

• Azure 서비스에 대한 로컬 인증을 제거합니다. Azure 서비스에 대한 로컬 인증 방법을 피하고 Microsoft Entra ID를 사용하여 인증을 중앙 집중화하고 암호 없는 방법(예: Windows Hello, FIDO2 키) 및 MFA(다단계 인증)를 사용하여 보안을 강화합니다.

메모: Active Directory 솔루션에 비해 Microsoft Entra는 강력한 인증, 조건부 액세스 정책 등의 이점을 제공합니다. 기술적으로 실현 가능한 즉시 내부 사용자의 인력 테넌트, 파트너 협업을 위한 Microsoft Entra B2B 또는 소비자용 앱의 Microsoft Entra 외부 ID 와 같은 구성을 사용하여 온-프레미스 Active Directory 기반 애플리케이션을 Microsoft Entra ID로 마이그레이션해야 합니다. 사용자 지정 특성이 필요한 레거시 앱에 Microsoft Entra Domain Services를 활용할 수도 있습니다.

구현 예제

시나리오: 금융 서비스 조직은 규정을 준수하고 횡적 이동을 방지하기 위해 프로덕션, 개발 및 파트너 환경 간에 엄격하게 격리된 중앙 집중식 ID 관리가 필요합니다.

구현 단계:

1. Microsoft Entra ID를 중앙 집중식 ID 공급자로 배포합니다.

   • 회사 ID에 대한 기본 테넌트(contoso.onmicrosoft.com) 만들기
   • 온-프레미스 AD 사용자를 동기화하도록 Microsoft Entra Connect Sync을 구성합니다.
   • 관리자에게 MFA가 필요한 위험 기반 정책 및 조건부 액세스에 Entra ID 보호 사용
   • SaaS 앱용 SSO 구성(Salesforce, ServiceNow, GitHub)
   • Azure 리소스에 대한 관리 ID 배포, Azure SQL/Storage에서 로컬 인증 제거
   • FIDO2 키 및 Windows Hello를 사용하여 암호 없는 인증 사용

2. 격리를 위한 디자인 관리 그룹 계층 구조:

Tenant Root Group
├── Corporate Production (finance-prod-sub, hr-prod-sub)
├── Corporate Non-Production (dev-sub, test-sub)
├── Partner Integration (partner-sub)
└── Customer-Facing Tenant (customer-prod-sub, customer-staging-sub)

3. ID 분리 구현:

   • 프로덕션 정체성: PAW가 있는 전용 관리 계정, 개발/테스트 액세스 없음
   • 개발 ID: 개발에서만 상승된 권한이 있는 표준 계정
   • 파트너 ID:시간이 제한된 액세스 권한이 있는 Microsoft Entra B2B
   • 고객 ID:Microsoft Entra 외부 ID를 사용하여 테넌트 구분

4. 구독 수준 격리 적용:

   • Azure RBAC을 구독 범위에서 할당 (prod-admin-group을 finance-prod-sub에서 소유자로만 지정)
   • 프로덕션 액세스를 위해 규정 준수 디바이스가 필요한 조건부 액세스 적용
   • 보안 기준에 대한 관리 그룹 수준에서 Azure Policy 구성
   • 환경당 별도의 Log Analytics 작업 영역 사용

5. 보안 컨트롤 구현:

   • 구독 제한 영역을 통해 청구, 리소스 및 권한을 격리하세요
   • Azure Firewall을 배포하여 환경 간 트래픽 제한
   • 통합 보안 모니터링을 위해 Defender for Cloud 사용
   • Azure Monitor로 Entra ID 감사 로그 스트리밍, 환경 간 액세스 시도에 대한 경고
   • Entra ID 거버넌스를 사용하여 분기별 액세스 검토 수행

결과:

조직은 모든 인증을 관리하는 단일 중앙 집중식 ID 플랫폼을 설정하여 조각화된 ID 사일로를 제거했습니다. 프로덕션 자격 증명은 엄격한 환경 분리를 통해 개발자 액세스에서 완전히 격리되어 개발 자격 증명의 손상이 프로덕션 워크로드에 영향을 주지 않도록 합니다. 일관된 MFA 및 조건부 액세스 정책은 모든 환경에 적용되며, 규정 준수는 포괄적인 감사 내역 및 의무 분리를 통해 유지 관리됩니다.

참조:Microsoft Entra ID 초보자 자습서

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: AC-2, AC-3, AC-4, AC-6, SC-2, SC-7
• PCI-DSS v4: 1.4.2, 7.2.1, 7.2.2, 8.2.1
• CIS 컨트롤 v8.1: 6.7, 12.5, 16.1
• NIST CSF v2.0: PR.AA-1, PR.AC-1, PR.AC-7
• ISO 27001:2022: A.5.15, A.5.16, A.8.2
• SOC 2: CC6.1, CC6.2, CC6.6

IM-2: ID 및 인증 시스템 보호

Azure Policy:Azure 기본 제공 정책 정의인 IM-2를 참조하세요.

보안 원칙

조직의 클라우드 보안 사례에서 높은 우선 순위로 ID 및 인증 시스템을 보호합니다. 일반적인 보안 제어는 다음과 같습니다.

• 권한 있는 역할 및 계정 제한
• 모든 권한 있는 액세스에 대해 강력한 인증 필요
• 고위험 활동 모니터링 및 감사

완화할 리스크

• Credential-Based 공격: 고정되지 않은 인증, 레거시 프로토콜(예: POP3, IMAP) 및 안전하지 않은 OAuth 2.0 동의 흐름은 악용 가능한 액세스 지점을 만들어 공격자가 자격 증명 또는 토큰(예: 무차별 암호 대입, 피싱 또는 OAuth 동의 남용을 통해)을 손상하여 시스템에 침투할 수 있도록 합니다.
• 권한 상승: 과도하게 프로비저닝된 RBAC 역할, 영구 권한 있는 액세스 및 과도한 전역 관리자 할당은 계정 인수 또는 PAC(권한 특성 인증서) 오용을 통해 공격자가 악용하여 액세스를 에스컬레이션하는 권한이 부여되지 않은 권한을 얻을 수 있도록 합니다.
• 리소스 경계 위반: 일관되지 않은 구독 거버넌스 및 환경 분리 부족으로 인해 공격자가 횡적 이동(예: 잘못 구성된 서비스 주체 악용)을 통해 악용되어 개발, 테스트 또는 prod 경계를 위반하는 리소스 간 액세스를 허용합니다.
• 테넌트 간 ID 오용: 약한 테넌트 간 인증 및 확인되지 않은 페더레이션 ID는 토큰 재생 또는 권한 없는 ID 페더레이션을 통해 공격자가 악용하여 외부 테넌트에 액세스하는 다중 테넌트 환경을 노출합니다.
• 액세스 지속성: 부적절한 ID 수명 주기 관리 및 모니터링되지 않는 액세스 검토는 장기 액세스를 유지하기 위해 휴면 계정 다시 활성화 또는 분리된 서비스 주체 남용을 통해 공격자가 악용하는 부실 또는 과도한 권한을 초래합니다.
• 위협 탐지 회피: 클라우드 및 온-프레미스 환경에서 조각화된 모니터링 및 구성되지 않은 실시간 경고는 Kerberos 공격(예: 통과 티켓) 또는 비정상적인 토큰 사용을 통해 공격자가 악용하여 탐지를 회피하는 악의적인 활동을 숨깁니다.
• 정책 구성 오류: 강제되지 않은 거버넌스 정책과 중앙 집중식 관리 그룹 컨트롤이 없으므로 잘못된 구성 조건부 액세스 또는 역할 할당을 통해 공격자가 제한을 우회하여 악용하는 일관성 없는 보안 설정이 발생할 수 있습니다.

MITRE ATT&CK

• 초기 액세스(TA0001): 연합되지 않은 ID 프로토콜 또는 잘못 구성된 OAuth 2.0 애플리케이션 동의를 악용하여 공격자가 무단 접근(예: T1078 - 유효한 계정)을 얻을 수 있습니다.
• 자격 증명 액세스(TA0006): 취약한 ID 구성에서 인증 토큰 또는 서비스 주체 비밀을 도난, 약한 저장소 또는 레거시 인증 방법을 악용하여 자격 증명 손상을 촉진(예: T1110 - 반복 공격).
• 권한 상승(TA0004): ID 시스템에서 지나치게 권한 있는 RBAC 할당 또는 잘못 구성된 PAC(권한 특성 인증서)를 활용하여 악의적 사용자가 중요한 리소스(예: T1134 - 액세스 토큰 조작)에 대한 액세스 권한을 높일 수 있도록 합니다.
• 횡적 이동(TA0008): 분리되지 않은 구독 또는 테넌트 간 ID 잘못된 구성을 악용하여 악의적 사용자가 환경 또는 테넌트 경계(예: T1578 - 클라우드 컴퓨팅 인프라 수정)를 트래버스할 수 있습니다.
• 지속성(TA0003): 모니터링되지 않는 ID 수명 주기 또는 분리된 서비스 주체의 조작으로 악의적 사용자가 부실 자격 증명(예: T1098 - 계정 조작)을 통해 장기간 액세스를 유지할 수 있습니다.
• 방어 회피(TA0005): 모니터링되지 않는 ID 활동 또는 Kerberos 티켓 조작을 악용하여 악의적 사용자가 비정상적인 토큰 사용(예: T1550 - 대체 인증 자료 사용)과 같은 악의적인 작업을 은폐할 수 있습니다.

IM-2.1: ID 보안 점수 평가

ID 보안 태세에는 구성 격차 및 보안 약점을 식별하는 측정 가능한 메트릭을 통한 지속적인 평가 및 개선이 필요합니다. ID 보안 점수는 인증 제어를 강화하고, 권한 있는 액세스 노출을 줄이고, 자격 증명 기반 공격을 방지하는 최신 보안 기능을 구현하기 위한 실행 가능한 권장 사항을 제공합니다. 정기적으로 보안 점수를 검토하는 조직은 높은 영향 향상을 식별하고, 수정 작업의 우선 순위를 지정하며, 업계 프레임워크 준수를 유지하면서 이해 관계자에게 보안 완성도를 보여 줍니다.

다음 방법을 통해 ID 보안 상태를 평가하고 개선합니다.

• ID 보안 점수 평가:ID 보안 점수를 사용하여 ID 보안 상태를 평가하고 구성 간격을 해결하고 관리 역할 할당, MFA 적용, 레거시 인증 상태 및 동의 정책을 평가합니다.

• 제한된 관리 역할 할당: 제한된 관리 역할을 할당하고 중복성을 위해 2-4 전역 관리자를 지정하면서 과도하게 프로비저닝하지 않도록 하여 최소 권한을 적용합니다.

• ID 보호 정책 사용: Microsoft Entra ID Protection을 통해 사용자 및 로그인 위험 정책을 사용하도록 설정하고 레거시 인증 프로토콜을 차단하여 안전하지 않은 액세스를 방지합니다.

• 다단계 인증 적용: 암호 없는 메서드(예: FIDO2, Windows Hello)를 지원하는 모든 사용자에 대해 MFA가 필요하고 권한 있는 액세스를 보호하기 위해 관리 역할에 대해 MFA를 위임합니다.

• 셀프 서비스 기능을 사용하도록 설정합니다. 보안 사용자 기반 복구를 위해 SSPR(셀프 서비스 암호 재설정)을 사용하도록 설정하고, 보안 및 유용성을 분산하는 고위험 계정(예: 권한 있는 역할)에 대한 암호 만료를 설정합니다.

• 애플리케이션 동의 제어: 사용자가 관리되지 않는 애플리케이션에 대한 동의를 부여하지 못하도록 제한하여 무단 액세스를 방지합니다.

• ID 위협 검색 배포: Microsoft Entra ID Protection을 활용하여 ID 기반 위험을 검색, 조사 및 수정합니다. 온-프레미스 Active Directory의 경우 Microsoft 365 Defender와 통합된 Microsoft Defender for Identity를 사용하여 하이브리드 환경을 모니터링하고 보호합니다.

참고: 온-프레미스 Active Directory, 타사 기능 및 호스팅 인프라(운영 체제, 네트워크, 데이터베이스)를 비롯한 다른 모든 ID 구성 요소에 대한 Microsoft 모범 사례를 따라 ID 및 액세스 보안을 보장합니다.

구현 예제

시나리오: 금융 서비스 조직은 지속적인 모니터링 및 위험 기반 보호를 사용하여 5,000명의 사용자와 200개 이상의 애플리케이션에서 ID 보안 상태를 개선해야 합니다.

구현 단계:

1. ID 보안 점수를 사용하여 기준 설정:

   • Microsoft Entra ID의 액세스 ID 보안 점수 대시보드(현재 점수: 62/100)
   • 우선 순위가 지정된 권장 사항 검토: 전역 관리자 감소(8→3), 권한 있는 계정에 MFA 적용, 레거시 인증 사용 안 함, 애플리케이션 동의 제한
   • 목표 점수 설정: 90일 이내에 85/100

2. 자동화된 위험 검색을 위해 Microsoft Entra ID Protection 을 배포합니다.

   • 위험 기반 정책 사용: 위험 수준이 높은 사용자의 암호 변경 필요, 중간/고위험 로그인에 MFA 필요
   • 유출된 자격 증명, 비정상적인 활동, 권한 에스컬레이션 시도에 대한 경고 구성
   • 상관 관계가 있는 위협 인텔리전스를 위해 Microsoft 365 Defender와 통합

3. 연속 모니터링 구현:

   • 주간 보안 점수 검토 및 일일 위험 감지 모니터링 설정
   • 자동화된 수정 구성: 위험 수준이 높은 IP 자동 차단, 손상된 자격 증명에 대한 암호 재설정 트리거, 비정상적인 동작에 대한 세션 해지
   • 부실 권한 할당을 제거하기 위해 분기별 액세스 검토 수행

결과:

조직은 지속적인 모니터링 및 위험 기반 보호를 통해 ID 보안 태세를 크게 개선했습니다. ID 보안 점수는 대상 시간 범위 내에서 크게 증가했으며, 전역 관리자 계정은 최소 권한 모범 사례에 맞게 축소되었습니다. MFA 적용 범위는 모든 권한 있는 계정에 대한 전체 배포에 도달했으며 레거시 인증 프로토콜을 사용하지 않도록 설정하여 공격 노출 영역을 크게 줄였습니다. 자동화된 위험 검색 및 대응 기능은 응답 시간을 크게 단축하는 반면, 사전 모니터링 및 자동화된 수정을 통해 자격 증명 기반 공격이 완전히 제거되었습니다.

참조::

• 일반 공급의 새 ID 보안 점수 권장 사항
• Microsoft Entra ID Protection을 사용하여 위험 모니터링 및 평가

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-4, IA-5, IA-8, SI-4
• PCI-DSS v4: 7.2.1, 8.2.1, 8.3.1, 8.3.2, 10.2.1
• CIS 컨트롤 v8.1: 5.4, 6.3, 6.5, 8.2
• NIST CSF v2.0: PR.AA-1, PR.AC-1, DE.CM-1
• ISO 27001:2022: A.5.15, A.5.16, A.5.17, A.8.5
• SOC 2: CC6.1, CC6.2, CC6.6, CC7.2

IM-3: 애플리케이션 ID를 안전하고 자동으로 관리

Azure Policy:Azure 기본 제공 정책 정의인 IM-3을 참조하세요.

보안 원칙

리소스에 액세스하고 코드를 실행하기 위해 애플리케이션에 대한 사용자 계정을 만드는 대신 관리되는 애플리케이션 ID를 사용합니다. 관리되는 애플리케이션 ID는 자격 증명 노출을 줄이는 등의 이점을 제공합니다. 자격 증명 회전을 자동화하여 ID의 보안을 보장합니다.

완화할 리스크

• 코드 또는 구성에서 Hard-Coded 자격 증명 노출: 소스 코드, 빌드 아티팩트 또는 구성 파일(예: .env, YAML)에 포함된 정적 자격 증명(예: API 키, 클라이언트 비밀)은 잘못 구성된 SCM 리포지토리(예: 공용 Git 리포지토리) 또는 CI/CD 파이프라인을 통해 노출되므로 악의적 사용자가 HTTP POST 요청 토큰 엔드포인트를 통해 클라우드 API에 인증할 수 있습니다.
• 피싱 또는 가로채기를 통한 자격 증명 도난: 악의적 사용자는 스피어피싱 캠페인(예: OAuth 동의 피싱) 또는 암호화되지 않은 HTTP/HTTPS 트래픽을 가로채는 MitM 공격을 통해 수명이 긴 자격 증명 또는 API 키를 캡처하고, 약한 TLS 구성을 악용하여 클라우드 서비스 인증을 위한 토큰을 획득합니다.
• 약한 자격 증명 또는 재사용된 자격 증명의 무단 액세스: 안전하지 않게 구성된 자격 증명(예: 낮은 엔트로피 암호, 재사용된 API 키)은 무차별 암호 대입 열거(예: REST API 호출을 통한 암호 분사) 또는 보안 위반 데이터 세트를 활용하는 자격 증명 스터핑 공격에 취약하여 클라우드 관리 API에 대한 액세스 권한을 부여합니다.
• Rogue 또는 Orphaned Accounts를 통한 영구 액세스: 악의적 사용자가 무단 계정을 만들거나 서비스 해제된 리소스에서 호출되지 않은 자격 증명을 악용하여 클라우드 오케스트레이션 템플릿(예: IaC 파일)에 정적 키를 포함하여 반복된 OAuth 2.0 토큰 교환을 통해 영구 액세스를 유지합니다.
• 과도한 권한을 가진 자격 증명에서 권한 상승: 범위가 과도한 자격 증명(예: 관리자 수준의 IAM 역할을 가진 API 키)을 사용하면 공격자가 잘못 구성된 RBAC 권한을 악용하여 높은 권한의 API 작업(예: 리소스 생성, 정책 수정)을 호출하여 권한을 상승시킬 수 있습니다.
• 손상된 시스템에서 자격 증명 수집: 악의적 사용자는 수집된 데이터를 사용하여 손상된 클라우드 인스턴스(예: 메모리 스크래핑을 통해) 또는 보안되지 않은 스토리지(예: S3 버킷, 구성 저장소)에서 일반 텍스트 자격 증명, API 키 또는 OAuth 토큰을 추출하여 횡적 이동을 위해 추가 클라우드 API에 인증합니다.
• 모니터링되지 않는 자격 증명 사용을 통한 검색 회피: 악의적 사용자는 도난당한 정적 자격 증명을 활용하여 합법적인 트래픽을 모방하는 API 요청을 생성하고, 비활성화된 감사 로깅을 악용하거나 클라우드 원격 분석에서 변칙 검색이 부족하여 탐지를 회피하고, 무단 액세스 식별을 지연시킵니다.

MITRE ATT&CK

• 초기 액세스(TA0001): 클라우드 애플리케이션 코드 또는 구성 파일에 포함된 하드 코딩된 자격 증명 또는 손상된 사용자 계정 악용, 피싱(T1566.001)을 활용하여 암호를 도용하거나 잘못 구성된 공용 API(T1190)를 악용하여 OAuth 2.0 또는 API 키 기반 엔드포인트를 통해 인증합니다.
• 자격 증명 액세스(TA0006): 소스 코드 리포지토리 또는 보안되지 않은 스토리지(T1003)에서 노출된 자격 증명을 대상으로 지정하고, 약한 사용자 암호(T1110.001)에 대한 무차별 암호 공격을 사용하거나, 클라우드 서비스 인증 흐름 중에 API 키 및 세션 토큰(T1539)을 가로채는 작업을 수행합니다.
• 지속성(TA0003): 악의적인 사용자 계정(T1136.003)을 만들거나 클라우드 애플리케이션 구성을 수정하여 영구 자격 증명(T1098.001)을 포함하여 액세스를 유지 관리하여 검색 없이 클라우드 리소스에 대한 반복적인 인증을 보장합니다.
• 권한 상승(TA0004): 손상된 사용자 계정 또는 과도한 권한이 있는 노출된 API 키가 악용되어 관리 액세스 권한을 얻습니다. 잘못 구성된 역할 기반 액세스 제어(T1548.004)를 악용하여 클라우드 리소스 또는 관리 API를 조작합니다.
• 방어 회피(TA0005): 공격자는 도난당한 API 키 또는 세션 토큰(T1606.002)을 위조하여 합법적인 클라우드 트래픽을 모방하거나 감사 로깅(T1562.001)을 사용하지 않도록 설정하여 탐지를 회피하고, 모니터링을 방지하기 위해 권한 있는 사용자(T1036)로 위장합니다.
• 컬렉션(TA0009): 손상된 클라우드 인스턴스 또는 스토리지(T1213.002)에서 하드 코딩된 자격 증명, API 키 또는 사용자 세션 데이터 수집, 구성 파일 또는 메모리 덤프(T1005)를 대상으로 하여 횡적 이동을 위한 중요한 데이터를 수집합니다.

IM-3.1: 지원되는 Azure 리소스에서 관리 ID 사용

관리 ID는 Microsoft Entra ID 인증을 지원하는 서비스에 인증하기 위해 자동으로 관리 ID를 Azure 리소스에 제공하여 자격 증명 노출을 제거합니다. 이러한 플랫폼 관리 자격 증명은 소스 코드 또는 구성 파일에서 하드 코딩된 비밀을 요구하지 않고 완전히 회전되고 보호되어 공격 표면 및 운영 오버헤드를 줄입니다. 관리 ID를 채택하는 조직은 Azure 리소스에서 원활한 서비스 간 인증을 사용하도록 설정하면서 자격 증명 도난을 방지하고, 비밀 관리를 간소화하고, 보안 규정 준수를 유지 관리합니다.

다음 단계를 사용하여 관리 ID를 구현합니다.

• 관리 ID를 선택하고 사용하도록 설정합니다. 사용 사례에 따라 시스템 할당(단일 리소스에 연결, 리소스로 자동 삭제) 또는 사용자 할당(독립 실행형, 여러 리소스에서 재사용 가능) 중에서 결정합니다. 리소스를 만드는 동안 관리 ID를 사용하도록 설정합니다(예: Azure App Service가 Key Vault에 액세스하기 위해 시스템 할당 ID를 사용하도록 설정).

• 최소 권한 할당: Azure 역할 기반 액세스 제어(RBAC)를 사용하여 대상 Azure 서비스에 관리 ID에 특정 역할(예: Key Vault 비밀 사용자 또는 스토리지 Blob 데이터 판독기)을 부여합니다.

• 애플리케이션 코드에서 인증 통합: DefaultAzureCredential과 함께 Azure SDK(예: .NET의 Azure.Identity, Python의 azure ID)를 사용하여 자격 증명을 포함하지 않고 Key Vault, SQL Database 또는 Storage와 같은 서비스에 인증합니다. 예를 들어 C#에서 var 자격 증명 = 새 DefaultAzureCredential(); Key Vault에서 비밀에 액세스하기 위한 토큰을 가져옵니다.

• 자동 토큰 새로 고침 사용: 애플리케이션이 토큰 새로 고침을 자동으로 처리하는지 확인합니다(토큰은 일반적으로 24시간 후에 만료됨).

IM-3.2: 관리 ID를 적용할 수 없는 서비스 주체 사용

서비스 주체는 관리 ID를 사용할 수 없는 서비스 및 애플리케이션에 대한 보안 인증을 제공하여 향상된 보안 제어를 사용하여 자격 증명 기반 액세스를 구현합니다. 조직은 최소 권한 RBAC 할당을 통해 엄격한 권한 경계를 유지하면서 노출 위험을 줄이기 위해 클라이언트 비밀보다 인증서 자격 증명의 우선 순위를 지정해야 합니다. 올바르게 구성된 서비스 주체는 보안 자동화 및 통합 시나리오를 가능하게 하며 비밀 회전 정책 및 보안 자격 증명 모음 스토리지를 통해 자격 증명 도난 위험을 최소화합니다.

다음 방법을 사용하여 서비스 주체를 구현합니다.

• Microsoft Entra ID에서 서비스 주체 만들기: Microsoft Entra ID를 사용하여 관리 ID를 지원하지 않는 서비스에 대한 서비스 주체를 만들어 애플리케이션 또는 서비스를 나타내는지 확인합니다(예: Azure Storage에 액세스해야 하는 레거시 서비스에 대한 앱 등록).

• 제한된 권한 구성: 리소스 수준에서 Azure Role-Based RBAC(Access Control)를 사용하여 서비스 주체에 최소 권한 권한을 할당합니다(예: 특정 스토리지 계정에 대한 Storage Blob 데이터 기여자).

• 인증서 기반 자격 증명 사용: 보안 강화를 위해 클라이언트 비밀보다 인증서 자격 증명을 선호합니다. 자체 서명된 인증서 또는 CA에서 발급한 인증서를 생성하고 Entra ID의 서비스 주체에 업로드합니다.

• 필요한 경우 클라이언트 비밀로 대체: 인증서를 사용할 수 없는 경우 정의된 만료(예: 1년)를 사용하여 Entra ID에 클라이언트 비밀을 만듭니다. 비밀을 Azure Key Vault에 안전하게 저장하고 프로그래밍 방식으로 검색하여 소스 코드 또는 구성 파일의 하드 코딩을 방지합니다. 만료 전에 비밀을 회전하고 사용하지 않는 비밀을 삭제하여 위험을 최소화합니다.

• 애플리케이션 코드에서 인증 통합: Azure SDK(예: Azure.Identity의 ClientCertificateCredential 또는 ClientSecretCredential)를 사용하여 애플리케이션 코드에서 서비스 주체의 자격 증명으로 인증합니다.

구현 예제

시나리오: 50개 이상의 애플리케이션이 있는 의료 조직에는 HIPAA 규정 준수를 위한 보안 인증이 필요하므로 코드 및 구성 파일에서 자격 증명이 제거됩니다.

구현 단계:

1. Azure 서비스에 대한 관리 ID 배포:

   • SharePoint 및 Azure SQL에 액세스하는 30개의 App Services에 대해 시스템 할당 ID 사용
   • Key Vault 및 Service Bus에 액세스하는 15개의 Azure Functions에 대한 사용자 할당 ID 구성
   • 백그라운드 처리 작업을 위해 VM에 관리 ID 배포
   • Azure.Identity SDK를 사용하여 애플리케이션 코드 리팩터링(DefaultAzureCredential)

2. 레거시 시스템에 대한 서비스 주체 구성 :

   • 인증서 기반 인증을 사용하여 5개의 서비스 주체 만들기(조직 PKI의 X.509)
   • 자동 회전을 사용하여 Azure Key Vault에 인증서 저장
   • 특정 리소스 그룹에 범위가 지정된 최소한의 권한을 가진 RBAC 역할 할당
   • CI/CD 파이프라인의 경우: 6개월 만료 및 자동화된 회전으로 클라이언트 비밀 사용

3. 모니터링 및 거버넌스 구현:

   • 관리 ID 없이 리소스를 감사하는 Azure Policy 배포
   • 자격 증명 노출을 감지하도록 Defender for Cloud 구성
   • 서비스 주체 권한에 대한 분기별 액세스 검토 설정
   • 비정상적인 서비스 주체 활동에 대한 로그인 로그 모니터링

결과:

조직은 대부분의 애플리케이션을 관리 ID로 성공적으로 마이그레이션하여 최신 클라우드 네이티브 서비스에서 자격 증명 관리가 필요하지 않습니다. 관리 ID를 채택할 수 없는 레거시 시스템은 자동 회전 기능이 있는 인증서 기반 서비스 주체를 사용하여 보호되었습니다. 모든 하드 코딩된 자격 증명은 애플리케이션 코드 및 구성 파일에서 제거되어 서비스 주체에 대한 자격 증명 회전의 완전한 자동화를 달성했습니다. 이 포괄적인 변환은 이전에 식별된 자격 증명 관리와 관련된 모든 규정 준수 감사 결과를 제거했습니다.

참조::

• 관리 ID를 사용하여 SharePoint Online 사이트에 대한 Azure 리소스 액세스 권한 부여
• Azure 서비스 주체 계정 작업

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-4, IA-5, IA-9, SC-12, SC-13
• PCI-DSS v4: 8.2.1, 8.2.2, 8.3.1, 8.5.1
• CIS 컨트롤 v8.1: 6.7, 12.5, 16.1, 16.9
• NIST CSF v2.0: PR.AA-1, PR.AC-1, PR.DS-1
• ISO 27001:2022: A.5.15, A.8.3, A.8.5
• SOC 2: CC6.1, CC6.2

IM-4: 서버 및 서비스 인증

Azure Policy:Azure 기본 제공 정책 정의인 IM-4를 참조하세요.

보안 원칙

클라이언트 쪽에서 원격 서버 및 서비스를 인증하여 신뢰할 수 있는 서버 및 서비스에 연결하도록 합니다. 가장 일반적인 서버 인증 프로토콜은 TLS(전송 계층 보안)입니다. 여기서 클라이언트 쪽(종종 브라우저 또는 클라이언트 디바이스)은 신뢰할 수 있는 인증 기관에서 서버의 인증서를 발급했는지 확인하여 서버를 확인합니다.

참고: 서버와 클라이언트가 서로 인증할 때 상호 인증을 사용할 수 있습니다.

완화할 리스크

• 무단 액세스: 공격자가 누락되거나 결함이 있는 인증을 악용하여 서비스 또는 클라이언트를 가장하고 API, 스토리지 또는 컴퓨팅 리소스에 액세스합니다. 이렇게 하면 데이터 반출, 페이로드 주입 또는 시스템 인수가 가능합니다. 예를 들어 인증되지 않은 서비스 간 요청은 Azure Storage에서 중요한 Blob을 추출할 수 있지만 유효성 검사를 우회하는 클라이언트는 백 엔드 API를 직접 조작할 수 있습니다.
• 자격 증명 도난 또는 누출: 코드, 구성 또는 로그의 하드 코딩되거나 노출된 자격 증명(예: 클라이언트 비밀, 토큰)은 공격자가 수집하여 영구 리소스 액세스 권한을 부여합니다. 도난당한 AAD 앱 비밀은 신뢰할 수 있는 서비스를 무기한 사칭할 수 있게 하여, 해지될 때까지 모든 지정된 범위의 엔드포인트에 액세스할 수 있습니다. 약한 비밀 회전 또는 암호화되지 않은 스토리지는 노출을 증폭합니다.
• MITM(Man-in-the-Middle) 공격: 악의적 사용자가 보안되지 않은 통신을 가로채거나 토큰을 훔치거나 요청을 변경합니다. 상호 인증이 없으면 공격자가 ID를 스푸핑하여 데이터 무결성을 손상할 수 있습니다. 예를 들어 암호화되지 않은 서비스 대 서비스 호출이 JWT를 누출하여 위조된 API 요청을 사용하도록 설정할 수 있습니다. 약한 TLS 암호화 또는 누락된 인증서 유효성 검사는 취약성을 높입니다.
• 권한 상승: 지나치게 허용된 ID 또는 잘못 구성된 범위를 사용하면 공격자가 권한 없는 리소스에 액세스하거나 권한 있는 작업을 실행할 수 있습니다. RBAC 역할이 과도한 서비스 주체(예: "소유자")는 악의적인 리소스를 배포할 수 있지만, 광범위한 사용자 권한이 있는 클라이언트는 중요한 구성을 변경하여 제한에서 모든 권한으로 에스컬레이션할 수 있습니다.

MITRE ATT&CK

• 초기 액세스(TA0001): 공격자는 도난당한 클라이언트 자격 증명(T1078.004) 또는 사용자 토큰(T1566.002)에 대한 피싱을 사용하여 서비스-서비스 또는 클라이언트-서비스 흐름에서 약한 인증을 악용하여 환경에 침투합니다. 예를 들어 잘못 설정된 OAuth 2.0 앱 등록이 위조된 토큰을 통해 무단 API 액세스(T1133)를 허용하여 스토리지나 컴퓨팅 리소스에 대한 접근을 지원합니다.
• 자격 증명 액세스 (TA0006): 공격자는 코드 리포지토리, 로그 또는 보안되지 않은 저장소(T1552.001)에서 노출된 클라이언트 비밀 정보, 인증서 또는 JWT를 대상으로 합니다. 기술에는 CI/CD 파이프라인(T1552.004)에서 서비스 주체 자격 증명을 스크래핑하거나 클라이언트 인증(T1539) 중에 새로 고침 토큰을 가로채 보호된 API에 대한 영구 액세스를 사용하도록 설정하는 것이 포함됩니다.
• 컬렉션(TA0009): 공격자는 손상된 리소스에서 액세스 토큰 또는 세션 데이터와 같은 인증 아티팩트(T1213.002)를 수집합니다. 여기에는 애플리케이션 구성(T1552.001)에서 하드 코딩된 비밀을 추출하거나 보안되지 않은 서비스 간 호출(T1040)에서 MITM을 통해 전송 중인 토큰을 캡처하여 추가 공격을 유발하는 것이 포함됩니다.
• 권한 상승(TA0004): 과도한 역할 기반 권한이 있는 손상된 서비스 주체 또는 사용자 계정은 상승된 액세스 권한을 얻기 위해 남용됩니다(T1078.004). 공격자는 잘못 구성된 앱 권한(T1548.004)을 악용하여 리소스 구성을 수정하거나 관리자 역할을 할당하여 시스템 또는 테넌트에 대한 제어를 확대합니다.
• 방어 회피(TA0005): 공격자가 도난당한 토큰(T1606.002)을 위조하여 합법적인 트래픽을 모방하거나 클레임을 조작하여 API 유효성 검사(T1036.008)를 우회합니다. 감사 로깅(T1562.001)을 사용하지 않도록 설정하거나 관리 ID를 사용하여 일반 작업(T1078)과 혼합하면 모니터링 시스템에서 탐지를 피할 수 있습니다.

IM-4.1: 서버 및 서비스 인증

서버 및 서비스 인증은 분산된 구성 요소 간의 신뢰 관계를 설정하여 중간자 공격과 서비스 사칭 위협을 방지합니다. TLS(전송 계층 보안)는 클라이언트가 보안 통신을 설정하기 전에 신뢰할 수 있는 인증 기관에서 발급한 서버 인증서를 확인하는 서버 인증을 위한 표준 메커니즘을 제공합니다. 모든 서비스 통신에서 TLS 인증을 적용하는 조직은 전송 중인 데이터를 보호하고, 자격 증명 가로채기를 방지하며, 제로 트러스트 아키텍처에 필수적인 보안 서비스 간 상호 작용을 유지 관리합니다.

다음 방법을 통해 서버 및 서비스 인증을 구현합니다.

• 모든 서비스에 대해 TLS 인증을 사용하도록 설정합니다. 대부분의 Azure 서비스는 기본적으로 TLS 인증을 지원합니다. 기본적으로 TLS 인증을 지원하지 않거나 TLS 비활성화를 지원하는 서비스의 경우 항상 서버/클라이언트 인증을 지원하도록 설정되어 있는지 확인합니다.

• 클라이언트 애플리케이션에서 인증서 트러스트 확인: 클라이언트 애플리케이션은 핸드셰이크 단계에서 신뢰할 수 있는 인증 기관에서 서버 인증서를 발급했는지 확인하여 서버/클라이언트 ID를 확인하도록 설계되어야 합니다.

• 해당하는 경우 상호 TLS를 구현합니다 . API Management 및 API Gateway와 같은 서비스는 서버와 클라이언트가 서로를 인증하는 보안 강화를 위해 TLS 상호 인증을 지원합니다.

구현 예제

시나리오: 결제 처리 회사는 PCI-DSS 규정 준수를 충족하기 위해 모바일 애플리케이션, 백 엔드 서비스 및 결제 게이트웨이 간의 API 통신을 보호해야 합니다. 상호 인증을 사용하여 중간자 공격을 방지해야 합니다.

구현 단계:

1. 모든 서비스에 대해 TLS 1.2+를 적용합니다.

   • 모든 Azure App Services 및 API Management에서 최소 TLS 버전(1.2 이상) 구성
   • 모든 사용자 지정 도메인에 대해 DigiCert에서 신뢰할 수 있는 SSL/TLS 인증서 배포
   • HTTPS 전용 모드를 사용하여 HTTP 요청 리디렉션
   • "Encrypt=True" 및 "TrustServerCertificate=False"를 사용하여 Azure SQL Database 구성

2. 중요한 API에 대해 mTLS(상호 TLS)를 구현합니다.

   • App Service 구성에서 클라이언트 인증서 인증 사용
   • App Service에 신뢰할 수 있는 클라이언트 인증서 CA 업로드
   • 클라이언트 인증서의 유효성을 검사하도록 API Management 구성(지문, 만료, 발급자)
   • 각 파트너/모바일 앱 버전에 대해 고유한 클라이언트 인증서 발급
   • 적절한 액세스 제어를 사용하여 Azure Key Vault에 인증서 저장

3. 인증서 수명 주기 관리:

   • Azure 관리형 인증서에 대해 자동 인증서 회전 사용
   • 60일 이내에 만료되는 인증서에 대한 경고 설정
   • OCSP 구현(온라인 인증서 상태 프로토콜) 확인
   • 분기별 인증서 해지 테스트 구성

4. 클라이언트 애플리케이션 인증서 유효성 검사:

   • 모바일 뱅킹 앱에 대한 인증서 고정 구현(iOS/Android)
   • 애플리케이션 코드에서 서버 인증서 체인 유효성 검사
   • 디바이스 보안 enclave/키 집합에 클라이언트 인증서 저장

결과:

조직은 최신 TLS 표준을 사용하여 모든 API 통신의 완전한 암호화를 달성했으며, 향상된 보안이 필요한 고가용성 API 엔드포인트에 대해 상호 TLS가 구현되었습니다. Man-in-the-middle 공격은 구현 후 완전히 제거되었으며, 서비스 중단을 일으키는 인증서 관리 문제는 자동화를 통해 해결되었습니다. 운영 오버헤드 없이 지속적인 보안을 보장하는 자동화된 인증서 수명 주기 관리를 통해 모든 요구 사항에 대해 완전한 PCI-DSS 규정 준수를 달성했습니다.

참조::

• Azure App Service에서 TLS 상호 인증 구성

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: IA-9, SC-8, SC-13, SC-23
• PCI-DSS v4: 4.2.1, 6.2.4, 8.2.1
• CIS 컨트롤 v8.1: 3.10, 9.2, 13.3
• NIST CSF v2.0: PR.DS-2, PR.DS-5
• ISO 27001:2022: A.5.14, A.8.24
• SOC 2: CC6.6, CC6.7

IM-5: 애플리케이션 액세스에 SSO(Single Sign-On) 사용

보안 원칙

SSO(Single Sign-On)를 구현하여 클라우드 서비스, SaaS 애플리케이션 및 온-프레미스 환경에서 사용자 인증을 간소화하여 사용자 환경 및 보안을 강화합니다. SSO를 사용하면 사용자가 신뢰할 수 있는 ID 공급자를 통해 한 번 로그인하고 반복 로그인 없이 모든 권한 있는 리소스에 액세스할 수 있습니다. 이렇게 하면 암호 피로를 줄이고 자격 증명 확산을 최소화하며 중앙 집중식 MFA, 일관된 TLS 및 통합 모니터링을 적용하여 피싱, 무차별 암호 대입 공격 및 노출된 자격 증명과 같은 위험을 완화하여 안전하고 효율적인 액세스 관리를 보장합니다.

완화할 리스크

• 코드 또는 구성에서 Application-Specific 자격 증명 노출: 소스 코드 또는 구성 파일(예: .env, JSON)에 포함된 일반 텍스트 자격 증명(예: API 키, 암호)은 잘못 구성된 리포지토리 또는 CI/CD 파이프라인을 통해 노출되므로 악의적 사용자가 API 엔드포인트를 통해 클라우드 또는 온-프레미스 서비스에 인증할 수 있습니다.
• 여러 로그인 인터페이스에서 피싱을 통한 자격 증명 도난: 악의적 사용자는 스피어 피싱(예: 가짜 앱 관련 로그인 페이지)을 통해 자격 증명을 캡처하거나 암호화되지 않은 트래픽을 다양한 로그인 엔드포인트로 가로채 일관성 없는 TLS 구성을 악용하여 여러 시스템에 대한 자격 증명을 획득합니다.
• 약한 자격 증명 또는 재사용된 자격 증명의 무단 액세스: 서로 다른 앱에서 낮은 엔트로피 또는 재사용된 자격 증명은 무차별 암호 대입 공격(예: 앱 로그인 API를 통한 암호 살포) 또는 자격 증명 스터핑에 취약하여 클라우드 서비스, SaaS 또는 온-프레미스 리소스에 대한 액세스 권한을 부여합니다.
• 추적되지 않은 애플리케이션 계정을 통한 영구 액세스: 악의적 사용자는 개별 앱 데이터베이스에서 관리되지 않는 계정을 악용하여 중앙 집중식 해지 없이 사일로 시스템에 대한 반복적인 인증을 통해 액세스를 유지하기 위해 구성에 자격 증명을 포함합니다.
• 모니터링되지 않는 자격 증명 사용을 통한 탐지 회피: 악의적 사용자는 도난당한 자격 증명을 사용하여 조정되지 않은 시스템에서 합법적인 트래픽을 모방하고, 조각화된 감사 로깅 또는 중앙 집중식 원격 분석이 없어 탐지를 회피하고, 무단 액세스 식별을 지연합니다.

MITRE ATT&CK

• 자격 증명 액세스(TA0006) - 피싱: 스피어피싱 링크(T1566.001): 가짜 로그인 페이지는 앱 엔드포인트를 모방하여 자격 증명을 캡처하고 비 SSO 시스템에서 일관되지 않은 TLS를 악용합니다.
• 자격 증명 액세스(TA0006) - 보안되지 않은 자격 증명: 파일의 자격 증명(T1552.001): 잘못 구성된 Git 리포지토리 또는 CI/CD 아티팩트의 일반 텍스트 API 키 또는 암호가 추출됩니다.
• 초기 액세스(TA0001) - 유효한 계정(T1078): 도난당한 자격 증명이 Azure, SaaS 또는 온-프레미스 앱에 인증되어 SSO가 아닌 설정에서 MFA를 우회합니다.
• 지속성(TA0003) - 계정 조작(T1098): 관리되지 않는 앱 계정 또는 포함된 자격 증명은 해지 없이 반복되는 액세스를 보장합니다.
• 방어 회피(TA0005) - 위장(T1036): 도난당한 자격 증명은 사일로 시스템에서 탐지를 회피하기 위해 합법적인 API 트래픽을 모방합니다.

IM-5.1: 애플리케이션 액세스에 SSO(Single Sign-On) 사용

Single Sign-On은 사용자가 한 번 인증하고 반복 로그인 없이 모든 권한 있는 리소스에 액세스할 수 있도록 하여 암호 피로 및 자격 증명 확산을 제거합니다. 중앙 집중식 ID 공급자를 통한 SSO는 모든 애플리케이션에서 다단계 인증, 조건부 액세스 및 통합 감사 로깅을 비롯한 일관된 보안 정책을 적용합니다. SSO를 구현하는 조직은 피싱 취약성을 줄이고, 사용자 환경을 간소화하며, 액세스 패턴에 대한 포괄적인 가시성을 유지하면서 직원, 파트너 및 고객을 포함한 다양한 사용자 모집단을 지원합니다.

다음 방법을 사용하여 환경 전체에서 SSO를 구현합니다.

• SSO 구현 계획: SSO가 필요한 애플리케이션(클라우드, 온-프레미스, 고객 연결) 및 Azure 리소스를 식별합니다. 사용자를 엔터프라이즈(직원), 외부 신뢰할 수 있는(파트너) 또는 퍼블릭(고객)으로 분류합니다. 앱 호환성에 따라 프로토콜(예: OpenID Connect, SAML 2.0, OAuth 2.0)을 결정합니다.

• Microsoft Entra ID에서 SSO를 구성합니다. Microsoft Entra ID를 활용하여 SSO(Single Sign-On)를 통해 고객 연결 워크로드 애플리케이션에 대한 액세스를 간소화하여 중복 사용자 계정이 필요하지 않습니다. 필요에 따라 Entra 앱 등록 모듈에 애플리케이션을 등록하고 SAML 메타데이터 또는 OIDC 클라이언트 ID/비밀을 사용하여 SSO 설정을 구성합니다. 관리 평면 액세스를 위해 Azure RBAC 역할(예: 기여자)을 할당합니다.

• 엔터프라이즈 사용자에 대해 SSO를 사용하도록 설정합니다 . Entra Connect를 사용하여 엔트라 ID와 온-프레미스 Active Directory를 동기화하여 회사 자격 증명으로 원활한 SSO를 사용하도록 설정합니다.

• 외부 파트너에 대한 SSO 구성: ID 공급자를 통해 SSO를 지원하는 파트너 또는 탈중앙화 자격 증명 확인을 위해 Microsoft Entra 확인된 ID에 대해 외부 ID를 구성합니다.

• 공용 사용자에 대한 SSO를 구현합니다 . 고객용 앱에 Entra ID B2C를 사용하여 사용자의 외부 ID(예: 소셜 네트워크 ID)를 사용하여 SSO에 대한 사용자 흐름을 설정합니다.

• 조건부 액세스를 사용하여 액세스 보호: 조건부 액세스 정책을 만들어 MFA, 디바이스 준수 또는 위치 기반 규칙을 적용합니다. 고위험 사용자를 위해 MFA를 적용하고 Entra ID 거버넌스를 사용하여 액세스 프로비저닝/프로비전 해제(예: 계약자용 액세스 패키지 )를 자동화합니다.

구현 예제

시나리오: 12,000명의 직원, 500개 파트너 및 50,000명의 고객이 있는 글로벌 제조 회사는 75개 애플리케이션에서 인증을 통합하고, 암호 피로를 없애고, 지원 센터 티켓을 줄이면서 보안을 개선해야 합니다.

구현 단계:

1. 엔터프라이즈 애플리케이션에 대한 SAML SSO 구성:

   • 인벤토리 75개 애플리케이션: 45개의 SaaS 앱(Salesforce, ServiceNow), 20개의 온-프레미스 앱, 10개의 사용자 지정 Azure 앱
   • Salesforce에 대한 SAML 2.0 통합 구성(Entra ID 특성 매핑, JIT 프로비저닝 사용)
   • Microsoft.Identity.Web SDK를 사용하여 사용자 지정 Azure Web Apps에 대해 OpenID Connect 설정
   • Kerberos 제한 위임을 사용하여 20개의 온-프레미스 레거시 앱에 대한 Azure AD 애플리케이션 프록시 배포

2. 파트너에 대한 외부 ID 구성(B2B):

   • 프로젝트 관리 도구를 위한 B2B 협업을 통해 500명의 파트너 사용자 초대
   • 파트너가 자체 조직 자격 증명을 사용하도록 페더레이션된 SSO 사용
   • 시간 바인딩된 프로젝트 액세스를 사용하여 액세스 패키지 구현(자동 만료)
   • 테넌트 간 액세스 설정을 사용하여 5개 주요 파트너와 테넌트 간 신뢰를 설정하십시오.

3. 고객을 위해 Azure AD B2C를 배포합니다.

   • 지원 포털에 액세스하는 50,000명의 고객을 위한 B2C 테넌트 설정
   • 소셜 ID 공급자 구성(Microsoft, Google, Facebook)
   • B2C 발급 토큰으로 OAuth 2.0을 사용하여 고객 API 보호
   • 회사 로고가 있는 브랜드 인증 페이지

4. 조건부 액세스 및 거버넌스 구현:

   • 위험 기반 정책 구성(위험 수준이 높은 사용자에게 암호 변경 + MFA 필요, 레거시 인증 차단)
   • Salesforce, ServiceNow, Workday에 SCIM 기반 사용자 프로비저닝 사용
   • HR 기반 수명 주기 구현: 4시간 이내에 자동 프로비전, 1시간 이내에 자동 해지
   • 파트너에 대한 분기별 액세스 검토 및 중요한 앱에 대한 연간 인증 설정

결과:

조직은 직원, 파트너 및 고객에게 서비스를 제공하는 대규모 애플리케이션 포트폴리오에서 SSO를 성공적으로 사용하도록 설정하여 보안 및 사용자 환경을 크게 개선했습니다. 암호 재설정 티켓은 크게 감소했으며, 사용자는 반복되는 로그인 프롬프트를 제거하여 상당한 생산성을 얻었습니다. 피싱 감수성은 자격 증명 노출 지점이 적어 급격히 감소했습니다. 파트너 온보딩 시간은 자동화된 액세스 패키지를 통해 크게 감소했으며, 원활한 소셜 로그인 통합을 통해 고객 만족도가 특히 증가했습니다. 가장 중요한 것은 취약한 암호와 관련된 보안 인시던트가 완전히 제거되었다는 점입니다.

참조::

• 엔터프라이즈 애플리케이션에 SAML Single Sign-On 사용 - Microsoft Entra ID

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: IA-2, IA-4, IA-8, AC-2
• PCI-DSS v4: 8.2.1, 8.2.2, 8.3.1
• CIS 컨트롤 v8.1: 6.3, 6.5, 12.5
• PR.AA-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.5.16
• SOC 2: CC6.1, CC6.2

IM-6: 강력한 인증 컨트롤 사용

Azure Policy:Azure 기본 제공 정책 정의인 IM-6을 참조하세요.

보안 원칙

리소스에 대한 모든 액세스에 대해 중앙 집중식 ID 및 인증 관리 시스템에 강력한 피싱 방지 인증 제어(강력한 암호 없는 인증 또는 다단계 인증)를 적용합니다. 암호 자격 증명만을 기반으로 하는 인증은 안전하지 않고 인기 있는 공격 방법을 지원하지 않으므로 레거시로 간주됩니다.

강력한 인증을 배포할 때 먼저 관리자 및 권한 있는 사용자를 구성하여 가장 높은 수준의 강력한 인증 방법을 보장한 다음, 모든 사용자에게 적절한 강력한 인증 정책을 신속하게 배포합니다.

참고: 레거시 애플리케이션 및 시나리오에 레거시 암호 기반 인증이 필요한 경우 복잡성 요구 사항과 같은 암호 보안 모범 사례를 준수해야 합니다.

완화할 리스크

• 피싱 또는 가로채기를 통한 자격 증명 손상: 공격자는 피싱 또는 네트워크 스니핑을 통해 자격 증명을 캡처하고 OAuth 피싱 또는 세션 하이재킹을 악용하여 애플리케이션 및 리소스에 액세스합니다.
• 약한 자격 증명 또는 재사용 자격 증명: 예측 가능하거나 재사용된 암호를 사용하면 무차별 암호 대입 공격 또는 보안 위반 데이터베이스의 자격 증명 스터핑을 사용할 수 있습니다.
• 코드 또는 구성의 자격 증명 노출: 소스 코드 또는 구성 파일에서 하드 코딩된 자격 증명은 잘못된 구성 또는 내부자 오류를 통해 노출됩니다.
• 손상된 계정의 무단 액세스: 손상된 계정은 동작 모니터링 부족으로 인해 공격자에게 애플리케이션 및 리소스에 대한 광범위한 액세스를 제공합니다.
• 계정 확산 및 고아 계정: 중복되거나 버려진 계정(예: 이전 직원의 경우)은 공격자에 의해 악용되거나 오남용될 수 있습니다.
• 애플리케이션 간 일관성 없는 보안 정책: 앱의 다양한 보안 제어(예: MFA 부족)는 악용 가능한 취약성을 만듭니다.
• MitM(Man-in-the-Middle) 공격: 공격자가 인증 세션을 가로채 자격 증명 또는 토큰을 도용합니다.
• Over-Privileged 계정의 내부자 위협: 지나치게 부여된 권한으로 인해 직원 또는 파트너에 의해 의도적 또는 실수로 오용될 수 있습니다.
• 여러 로그인 지점을 통한 소셜 엔지니어링: 수많은 로그인 인터페이스가 사용자를 속여 자격 증명을 공개하는 공격 표면을 확장합니다.
• 권한 없는 외부 액세스: 제대로 관리되지 않는 외부 ID(예: 파트너, 고객)는 중요한 시스템에 의도하지 않은 액세스 권한을 얻습니다.

MITRE ATT&CK

• 자격 증명 액세스(TA0006): 수집된 자격 증명을 사용하여 클라우드 또는 온-프레미스 서비스 API에 인증하기 위해 수집된 자격 증명을 사용하여 소스 코드 또는 구성 파일(예: .env, JSON)에 포함된 일반 텍스트 자격 증명(예: API 키, 암호)을 잘못 구성된 리포지토리 또는 CI/CD 파이프라인에서 추출합니다.
• 초기 액세스(TA0001): 스피어 피싱(예: 가짜 앱별 로그인 페이지, T1566.001)을 통해 자격 증명을 캡처하거나 암호화되지 않은 트래픽을 가로채 로그인 엔드포인트를 분리하여 일관되지 않은 TLS 구성을 악용하여 여러 시스템에 대한 자격 증명을 획득합니다.
• 초기 액세스(TA0001): 조정되지 않은 앱에서 약하거나 재사용된 자격 증명을 악용하고, 무차별 암호 대입 공격(예: 앱 로그인 API를 통한 암호 살포, T1110.001) 또는 자격 증명 스터핑을 활용하여 클라우드 서비스, SaaS 또는 온-프레미스 리소스에 대한 무단 액세스를 얻습니다.
• 지속성(TA0003): 개별 앱 데이터베이스에서 관리되지 않는 계정을 악용하여 액세스를 유지 관리하고, 구성에 자격 증명을 포함(T1098.001)하여 중앙 집중식 해지 없이 사일로 시스템에 반복적으로 인증합니다.
• 방어 회피(TA0005): 도난당한 자격 증명을 사용하여 서로 다른 시스템에서 합법적인 트래픽을 모방한 API 또는 앱 요청을 생성하고, 조각화된 감사 로깅 또는 중앙 집중식 원격 분석 부족으로 인해 탐지(T1036)를 회피합니다.

IM-6.1: 강력한 인증 컨트롤 사용

강력한 인증은 암호에만 의존하지 않도록 하여 자격 증명 기반 공격을 방지하며, 피싱, 무차별 암호 대입 및 보안 위반 데이터베이스에 취약합니다. 암호 없는 옵션(생체 인식, 보안 키, 인증서 기반 인증) 및 다단계 인증을 비롯한 최신 인증 방법은 계정 손상 위험을 크게 줄이면서 사용자 환경을 개선합니다. 강력한 인증을 배포하는 조직은 먼저 관리자와 권한 있는 사용자의 우선 순위를 지정하여 높은 가치의 계정을 보호한 다음, 향상된 보안 정책을 통해 암호가 필요한 레거시 시나리오에 대한 지원을 유지하면서 모든 사용자에게 범위를 체계적으로 확장해야 합니다.

다음 방법을 사용하여 강력한 인증 제어를 구현합니다.

• 암호 없는 인증 배포: 사용 가능한 네 가지 옵션인 비즈니스용 Windows Hello, Microsoft Authenticator 앱 휴대폰 로그인, 암호 키(FIDO2) 및 인증서 기반 인증을 사용하여 암호 없는 인증을 기본 방법으로 사용합니다. Microsoft Entra ID는 기본적으로 암호 없는 인증을 지원합니다. 또한 고객은 스마트 카드와 같은 온-프레미스 인증 방법을 사용할 수 있습니다.

• 다단계 인증 적용: 로그인 조건 및 위험 요소에 따라 모든 사용자, 사용자 선택 또는 사용자별 수준에서 적용할 수 있는 Azure MFA 를 사용하도록 설정합니다. MFA 설정에 대한 Microsoft Defender for Cloud ID 및 액세스 관리 권장 사항을 따릅니다.

• 레거시 시나리오에 대한 암호 보안 유지 관리: 레거시 암호 기반 인증이 Microsoft Entra ID 인증에 계속 사용되는 경우 클라우드 전용 계정(Azure에서 직접 만든 사용자 계정)에는 기본 기준 암호 정책이 있고 하이브리드 계정(온-프레미스 Active Directory의 사용자 계정)은 온-프레미스 암호 정책을 따릅니다. 기본 ID와 암호가 있는 타사 애플리케이션 및 서비스의 경우 초기 서비스 설정 중에 사용하지 않도록 설정하거나 변경합니다.

구현 예제

시나리오: 직원이 8,000명인 기술 회사는 피싱 방지 암호 없는 인증을 배포하여 암호 기반 공격을 제거하고 사용자 환경을 개선해야 합니다.

구현 단계:

1. Microsoft Entra ID에서 인증 방법을 사용하도록 설정합니다.

   • Microsoft Entra 관리 센터 > 보호 > 인증 방법으로 이동
   • 모든 사용자에 대해 비즈니스용 Windows Hello 사용(기본 Windows 10/11 디바이스 인증)
   • 증명 적용이 예 로 설정된 FIDO2(Passkeys) 사용(FIDO Alliance MDS에서 확인된 보안 키만 확인)
   • 증명 강제 시행을 사용하여 Microsoft Authenticator(미리 보기)에서 패스키를 활성화합니다.
   • 인증서 기반 인증(CBA) 사용 및 신뢰할 수 있는 인증 기관 구성
   • 대체 MFA 방법 구성: Microsoft Authenticator 푸시 알림, OATH 토큰(권한 있는 사용자의 SMS/음성 방지)

2. 인증 강도 정책 정의:

   • FIDO2 보안 키 또는 비즈니스용 Windows Hello 또는 플랫폼 SSO 또는 인증서 기반 인증(다단계)을 요구하는 사용자 지정 인증 강도 "관리자 피싱 방지" 만들기
   • 표준 사용자(Windows Hello, FIDO2, Authenticator passkeys, CBA 포함)에 기본 제공 "암호 없는 MFA 강도" 사용
   • 레거시 애플리케이션 액세스에 대한 대체로 기본 제공 "다단계 인증 강도"를 사용합니다.

3. 권한 있는 사용자(관리자 150명)를 위한 피싱 방지 인증 배포:

   • 플랫폼 간 호환성을 위해 USB-A/C 및 NFC 지원(YubiKey 5 시리즈)을 사용하여 FIDO2 보안 키 구매
   • 모든 관리자에게 키를 배포하고 Microsoft Entra 보안 정보 페이지에서 등록을 안내합니다.
   • PIN 복잡성 요구 사항이 있는 TPM 2.0을 사용하여 100개 Windows PAW에서 비즈니스용 Windows Hello 구성
   • 관리자 역할을 대상으로 하는 조건부 액세스 정책 만들기(전역 관리자, 보안 관리자 등): 모든 Azure Portal 및 관리자 앱 액세스에 대해 "관리자 피싱 방지" 인증 강도 필요
   • 결과: 100%의 관리자 로그인이 하드웨어 지원 피싱 저항 방법을 사용하며, 장비의 인증을 통해 불량 기기의 등록을 방지합니다.

4. 최종 사용자(7,850명)에 대한 암호 없는 인증 롤아웃:

   • Windows 사용자(6,500명): TPM 2.0 또는 생체 인식 센서(지문, 얼굴 인식)를 사용하여 Intune을 통해 비즈니스용 Windows Hello 배포
   • 모바일 사용자(1,200명): iOS/Android 용 Microsoft Authenticator (미리 보기)에서 암호 사용
     • iOS: FaceID/TouchID와 함께 Secure Enclave를 사용하는 디바이스 바인딩된 암호
     • Android: 생체 인식 인증을 통한 보안 모듈 또는 신뢰할 수 있는 실행 환경(TEE)을 사용하는 디바이스 고유 암호
     • 앱 증명(iOS) 및 Android(Play Integrity API)를 통해 증명을 사용하도록 설정하여 합법적인 Authenticator 앱을 확인합니다.
   • IT 및 재무 부서의 500명의 초기 수용자와 함께 파일럿 진행
   • 디바이스 바인딩된 암호만 등록되도록 증명 적용 을 예 로 설정(비준수 암호 공급자 차단)
   • 표준 사용자에 대한 조건부 액세스 정책 만들기: 회사 애플리케이션에 액세스하려면 "암호 없는 MFA 강도" 인증 필요
   • 주소 에지 사례: 생체 인식 가능 디바이스가 없는 사용자는 FIDO2 보안 키를 받습니다.

5. 특수 시나리오에 대한 CBA(인증서 기반 인증)를 배포합니다.

   • PKI 통합이 필요한 100명의 외부 계약자에 대한 Microsoft Entra 인증서 기반 인증 구성
   • 2년 유효 기간으로 조직 CA에서 X.509 인증서 발급
   • 다단계 인증에 대한 CBA 인증 바인딩 정책 구성: certificatePolicyOid + 사용자 이름 바인딩 필요(강력한 MFA)
   • 하드웨어 보안 모듈(스마트 카드) 또는 디바이스 보안 스토리지(TPM, Secure Enclave)에 인증서 저장
   • 관리자 액세스 권한이 있는 계약자에 대한 "관리자 피싱 방지" 인증 강도 정책에 CBA 포함

6. 인증 강도가 있는 조건부 액세스 정책을 구성합니다.

   • 정책 1 - 관리자 보호: Azure Portal, Microsoft 365 관리 센터에 적용할 → "관리자 피싱 방지" 강도 필요 → 모든 관리자 역할을 대상으로 지정
   • 정책 2 - 표준 사용자: 모든 사용자(관리자 제외) → 모든 클라우드 앱에 적용하기 → "암호 없는 MFA 강도" 필요
   • 정책 3 - 레거시 앱: 암호 없는 지원이 불가능한 특정 레거시 애플리케이션을 대상으로 지정 → "다단계 인증 강도"가 필요 (암호 + Authenticator 푸시/OTP 허용).
   • 정책 4 - 외부 액세스: 대상 게스트/외부 사용자 → 최소 "다단계 인증 강도" 필요
   • 인증 강도 준수 및 정책 효율성에 대한 조건부 액세스 인사이트 모니터링

7. 레거시 애플리케이션 지원 및 암호 보안(15개 앱):

   • 최신 인증을 지원할 수 없는 애플리케이션 식별(SAP GUI, 암호가 필요한 레거시 VPN)
   • 이러한 앱의 경우 조건부 액세스를 통해 "다단계 인증 강도"를 요구합니다(암호 + Authenticator 푸시 알림/OTP 허용).
   • Microsoft 365용 조건부 액세스를 통해 레거시 인증 프로토콜(POP3, IMAP, SMTP AUTH) 차단
   • 나머지 암호 사용자에 대해 사용자 지정 금지 암호 목록을 사용하여 Microsoft Entra 암호 보호를 활성화
   • 최신 인증 프로토콜을 지원하도록 레거시 애플리케이션에 대한 마이그레이션 경로 계획(OAuth 2.0, SAML 2.0)

8. 암호 제거 및 복구 메커니즘:

   • 최신 애플리케이션에 암호 없는 인증 강도가 필요한 조건부 액세스 정책 적용
   • 암호 없는 자격 증명을 등록한 사용자의 95% 암호 인증 사용 안 함
   • 계정 복구 및 초기 암호 없는 자격 증명 등록을 위한 TAP( 임시 액세스 패스 ) 구성
   • 레거시 앱 액세스가 필요한 사용자의 5% 암호 기능 유지 관리

9. 모니터링 및 지속적인 개선:

   • Microsoft Entra 관리 센터에서 인증 방법 대시보드 모니터링
   • 메트릭 추적: 방법별 암호 없는 채택률(Windows Hello: 81%, Authenticator passkeys: 15%, FIDO2: 2%, CBA: 1%, 플랫폼 SSO: 1%)
   • 조건부 액세스 인사이트에서 인증 강도 준수 검토
   • 사용된 인증 방법, 인증 강도 평가 및 차단된 레거시 인증 시도에 대한 로그인 보고서 모니터링
   • 비준수 디바이스를 등록하려는 사용자를 식별하기 위한 인증 실패 감사
   • 기준: 암호 없는 시스템 도입 전, 월 15건의 자격 증명 손상 경고 발생
   • 대상: <비밀번호 없는 상태에서 매월 경고 2개

결과:

조직은 피싱 방지 인증 방법을 사용하여 모든 주요 플랫폼에서 포괄적인 암호 없는 채택을 달성했습니다. 하드웨어 지원 자격 증명(FIDO2, Windows Hello, Platform SSO, CBA)을 사용하여 권한 있는 계정에 대해 완전한 적용을 수행하여 높은 가치의 대상에 대한 암호 기반 위험을 제거했습니다. 암호 없는 인증 채택은 플랫폼 네이티브 솔루션(Windows Hello 81%, Authenticator passkeys 15%, FIDO2 2%, CBA 1%, 플랫폼 SSO 1%)을 통해 직원 전체에서 95개의% 도달했습니다. 암호 기반 보안 인시던트가 완전히 제거된 반면 피싱 시뮬레이션 실패율은 배포 후 18% <에서 2%로 감소했습니다. 지원 센터 암호 재설정 티켓은%87장 감소하여 인증 지원에서 연간 340,000달러의 비용을 절감했습니다. 사용자는 생체 인식 방법으로 40% 더 빠른 인증을 경험하여 간소화 된 액세스를 통해 생산성을 얻었습니다. 인증 강도 정책은 세분화된 적용을 보장하여 인증 방법을 다운그레이드하는 공격을 방지하고 모든 관리자 액세스 시나리오에서 일관된 피싱 방지 요구 사항을 유지했습니다.

참조::

• Microsoft Authenticator에서 암호 사용(미리 보기)
• Microsoft Entra 인증서 기반 인증
• 조건부 액세스의 인증 강도

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-5, IA-8, IA-11
• PCI-DSS v4: 7.2.1, 8.2.1, 8.3.1, 8.3.2, 8.4.2
• CIS 컨트롤 v8.1: 6.3, 6.4, 6.5
• PR.AA-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.5.17, A.5.18
• SOC 2: CC6.1, CC6.2

IM-7: 조건에 따라 리소스 액세스 제한

보안 원칙

제로 트러스트 액세스 모델의 일부로 리소스에 대한 사용자 액세스를 허용하거나 거부하는 신뢰할 수 있는 신호의 유효성을 명시적으로 검사합니다. 유효성을 검사하는 신호에는 사용자 계정의 강력한 인증, 사용자 계정의 동작 분석, 디바이스 신뢰도, 사용자 또는 그룹 멤버 자격, 위치 등이 포함되어야 합니다.

완화할 리스크

• 과도한 권한의 자격 증명 또는 계정으로 인한 권한 상승: 악의적 사용자는 공유 자격 증명 또는 사용자 계정을 전반적인 관리자 액세스와 같은 광범위한 권한으로 악용하여, 관리 엔드포인트에 대한 HTTP 요청(예: REST API)을 통해 리소스 생성, 삭제 또는 정책 수정 같은 높은 권한의 클라우드 API 작업을 호출합니다.
• 도난당한 Broad-Scope 자격 증명을 통한 무단 액세스: 악의적 사용자는 스피어피싱 또는 잘못 구성된 퍼블릭 엔드포인트를 통해 획득한 제대로 관리되지 않는 액세스 시스템에서 도난당한 자격 증명을 사용하여 세분화된 리소스 관련 제한 사항이 없는 암호를 통해 클라우드 서비스에 인증합니다.
• 관리되지 않는 계정 또는 과도한 계정을 통한 영구 액세스: 악의적 사용자는 광범위한 권한으로 관리되지 않는 계정을 만들거나 수정하여 클라우드 구성(예: IaC 템플릿)에 정적 자격 증명을 포함하여 중앙 집중식 권한 해지 없이 반복되는 API 인증을 통해 영구 액세스를 유지합니다.
• 광범위한 범위의 자격 증명 사용으로 탐지 회피: 악의적 사용자는 광범위한 범위의 자격 증명을 활용하여 합법적인 클라우드 트래픽을 모방하는 API 요청을 생성하고, 역할별 감사 내역이 없거나 거친 액세스 제어 시스템에서 세분화된 모니터링이 없어 탐지를 회피합니다.
• 지나치게 액세스 가능한 리소스에서 무단 데이터 또는 자격 증명 수집: 악의적 사용자는 스토리지 버킷 또는 가상 머신과 같은 클라우드 리소스에서 중요한 데이터 또는 자격 증명(예: API 키, 사용자 데이터)을 추출하여 역할 기반 경계 누락으로 인해 무제한 API 쿼리 또는 파일 액세스를 허용하는 허용 액세스 제어를 활용합니다.

MITRE ATT&CK

• 권한 상승(TA0004): 광범위한 액세스 범위가 있는 과도하게 권한 있는 공유 자격 증명 또는 사용자 계정을 악용하고, 허용되는 액세스 제어를 남용하여 서비스 간에 높은 권한의 클라우드 API 작업(예: 리소스 생성, 정책 수정)을 호출합니다.
• 초기 액세스(TA0001): 거친 관리형 액세스 시스템에서 도난당한 자격 증명을 활용하고, 스피어 피싱 또는 잘못 구성된 공용 엔드포인트를 사용하여 세분화된 제한 사항이 없는 API 키 또는 암호를 통해 인증합니다.
• 지속성(TA0003): 과도한 권한으로 관리되지 않는 계정을 만들거나 수정하여 액세스를 유지 관리하고, 역할 기반 해지 없이 반복적으로 인증하도록 클라우드 구성에 자격 증명을 포함합니다.
• 방어 회피(TA0005): 광범위한 범위의 자격 증명을 사용하여 합법적인 클라우드 API 트래픽(T1036)을 모방하고, 역할별 감사 내역 또는 모니터링 부족으로 인한 검색을 회피하고, 거친 액세스 로깅 메커니즘을 우회합니다.
• 컬렉션(TA0009): 역할 기반 액세스 경계가 없어 스토리지 또는 인스턴스에서 API 키 또는 사용자 데이터를 추출하는 액세스 권한이 지나치게 허용된 클라우드 리소스에서 중요한 데이터 또는 자격 증명을 수집합니다.

IM-7.1: 조건에 따라 리소스 액세스 제한

조건부 액세스 정책을 사용하면 리소스 액세스 권한을 부여하기 전에 여러 신호를 동적으로 평가하고 정적 권한을 넘어 컨텍스트 인식 액세스 제어로 이동하여 제로 트러스트 보안을 사용할 수 있습니다. 조직은 관리 작업에 MFA를 요구하거나, 레거시 인증 프로토콜을 차단하거나, 중요한 애플리케이션에 대한 규격 디바이스를 의무화하는 등의 적응형 보안 요구 사항을 적용하기 위해 조건부 액세스를 구현합니다. 이러한 정책은 보안 요구 사항과 사용자 생산성의 균형을 맞추면서 인증 세션에 대한 세부적인 제어를 제공하여 실시간 위험 평가에 따라 적절한 보호 수준을 보장합니다.

다음 방법을 사용하여 조건부 액세스 제어를 구현합니다.

• Microsoft Entra 조건부 액세스 배포: 특정 IP 범위(또는 디바이스)의 사용자 로그인이 MFA를 사용하도록 요구하는 등 사용자 정의 조건에 따라 세분화된 액세스 제어에 Microsoft Entra 조건부 액세스를 사용합니다. Microsoft Entra 조건부 액세스를 사용하면 특정 조건에 따라 조직의 앱에 액세스 제어를 적용할 수 있습니다.

• 적용 가능한 조건 및 조건을 정의합니다. 워크로드에서 Microsoft Entra 조건부 액세스에 대한 적용 가능한 조건 및 조건을 정의할 때 다음과 같은 일반적인 사용 사례를 고려합니다.

• 관리 역할에 MFA 필요: 관리 역할이 있는 사용자에 대한 다단계 인증이 필요합니다.

• 관리 작업에 MFA 필요: Azure 관리 작업에 다단계 인증이 필요합니다.

• 레거시 인증 프로토콜 차단: 레거시 인증 프로토콜을 사용하려는 사용자의 로그인을 차단합니다.

• 신뢰할 수 있는 위치 적용: 다단계 인증 등록을 위해 신뢰할 수 있는 위치가 필요하고 특정 위치에서 액세스를 차단하거나 부여합니다.

• 위험한 로그인 동작 차단: 위험한 로그인 동작을 차단합니다.

• 관리되는 디바이스 필요: 특정 애플리케이션에 대해 조직 관리 디바이스가 필요합니다.

• 세션 관리 컨트롤 구현: 로그인 빈도 및 영구 브라우저 세션과 같은 Microsoft Entra 조건부 액세스 정책을 통해 세분화된 인증 세션 관리 컨트롤을 구현할 수도 있습니다.

구현 예제

시나리오: 직원이 3,500명인 의료 조직은 HIPAA 규정 준수를 보장하면서 150개의 Azure 리소스 및 45개 애플리케이션에 대한 제로 트러스트 액세스 제어가 필요합니다. RBAC(Role-Based Access Control) 기본 사항을 이해하는 것이 중요합니다.

구현 단계:

1. RBAC 기준 설정:

   • 역할 계층 정의: 전역 관리자(3), 보안 관리자(8), 애플리케이션 관리자(25), 표준 사용자(3,464)
   • 의료 시나리오에 대한 사용자 지정 Azure 역할 만들기(PHI 데이터 판독기, 임상 애플리케이션 관리자, 감사 검토자)
   • 적절한 범위에서 역할 할당(인프라에 대한 구독 수준, 애플리케이션의 리소스 그룹 수준)
   • 규정 준수 추적을 위해 Microsoft Intune에 4,200개 디바이스 등록

2. 8가지 조건부 액세스 정책을 배포합니다.

   • 정책 1 - MFA 기준: 모든 사용자, 모든 클라우드 앱에는 MFA가 필요합니다(로그인 빈도: 8시간)
   • 정책 2 - 권한 있는 역할 보호: 관리자는 MFA + 규격 디바이스 + 승인된 클라이언트 앱(4시간 세션)이 필요합니다.
   • 정책 3 - Azure 관리: portal.azure.com 액세스를 위해 MFA + 규격 디바이스 + 하이브리드 Azure AD 조인 필요
   • 정책 4 - 레거시 인증 블록: POP3, IMAP, SMTP AUTH 차단(6개월 일몰 계획이 있는 15개의 임시 예외)
   • 정책 5 - 신뢰할 수 있는 위치: 신뢰할 수 없는 위치에서 PHI에 액세스하려면 MFA를 요구합니다; Tor/익명 프록시를 차단합니다.
   • 정책 6 - 위험 기반 제어: 중간 또는 높은 로그인 위험에 대해 MFA 및 암호 변경 요구(Entra ID Protection 통합)
   • 정책 7 - 관리되는 디바이스: SharePoint/Azure Web Apps에 대한 규격 또는 하이브리드 Azure AD 조인 디바이스 필요
   • 정책 8 - 애플리케이션 전용 세션: 금융 시스템을 위한 30분 세션, PHI(개인 건강 정보)에 대한 다운로드/복사/붙여넣기 차단

3. CAE(지속적인 액세스 평가)를 사용하도록 설정합니다.

   • 사용자가 사용하지 않도록 설정하거나 암호가 변경되거나 위험 수준이 높은 위치로 이동한 경우 즉시 토큰 해지
   • 중요한 이벤트에 대해 15분 이내에 해지된 토큰

4. 모니터링 및 최적화:

   • 매주 조건부 액세스 인사이트 검토(정책 영향, 사용자 환경 메트릭)
   • 비상 액세스 계정, 레거시 시스템을 포함한 45개의 예외를 관리하며, 분기별 검토를 수행합니다.
   • 관련자와의 월간 정책 검토 회의

결과:

조직은 완전한 MFA 적용 범위와 높은 관리형 디바이스 채택을 가진 모든 사용자를 포괄하는 포괄적인 조건부 액세스 정책을 배포했습니다. 특정 비즈니스 요구 사항에 대해 제한된 예외를 제외하고 거의 모든 요청에 대해 레거시 인증이 차단되었습니다. 이제 모든 관리자 계정에는 호환 디바이스와 결합된 피싱 방지 MFA가 필요합니다. 보호된 상태 정보에 대한 무단 액세스가 크게 감소하고 위치 기반 변칙이 자동으로 차단되어 이전에 발생한 위반을 방지합니다. 조직의 HIPAA 준수 점수가 크게 향상되어 상당한 보안 완성도를 입증했습니다.

참조::

• Azure에서의 역할 기반 액세스 제어 기초 가이드

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, AC-16
• PCI-DSS v4: 7.2.1, 7.2.2, 7.2.3
• CIS 컨트롤 v8.1: 3.3, 6.4, 6.8, 13.5
• NIST CSF v2.0: PR.AC-1, PR.AC-4, PR.AA-1
• ISO 27001:2022: A.5.15, A.5.18, A.8.2, A.8.3
• SOC 2: CC6.1, CC6.3, CC6.6

IM-8: 자격 증명 및 비밀 노출 제한

Azure Policy:Azure 기본 제공 정책 정의인 IM-8을 참조하세요.

보안 원칙

애플리케이션 개발자가 자격 증명 및 비밀을 안전하게 처리해야 합니다.

• 자격 증명 및 비밀을 코드 및 구성 파일에 포함하지 마세요.
• 키 보관소 또는 보안 키 저장소 서비스를 사용하여 자격 증명과 비밀을 저장하다
• 소스 코드에서 자격 증명을 검색합니다.

참고: 이는 종종 SDLC(보안 소프트웨어 개발 수명 주기) 및 DevOps 보안 프로세스를 통해 제어되고 적용됩니다.

완화할 리스크

• 권한 없는 액세스: 일반 텍스트, 코드 리포지토리 또는 로그의 노출된 자격 증명(예: API 키, 암호)을 공격자가 악용하여 중요한 시스템 또는 데이터에 액세스할 수 있습니다. 예를 들어 유출된 Azure 서비스 주체 키를 사용하면 공격자가 스토리지 계정 또는 가상 머신에 액세스할 수 있습니다.
• 권한 상승: 권한이 초과된 서비스 계정 토큰과 같은 손상된 비밀을 통해 공격자는 클라우드 환경 내에서 액세스 권한을 높일 수 있으며, 잠재적으로 전체 구독 또는 중요한 리소스(예: 도난당한 Key Vault 비밀을 사용하여 관리 기능에 액세스)를 제어할 수 있습니다.
• 데이터 위반: 노출된 데이터베이스 연결 문자열 또는 스토리지 계정 키는 무단 데이터 추출로 이어져 고객 레코드 또는 지적 재산과 같은 중요한 정보를 노출할 수 있으며, 종종 공용으로 잘못된 구성(예: 개방형 Azure Blob 컨테이너)을 통해 노출됩니다.
• 횡적 이동: 도난당한 자격 증명을 사용하면 공격자가 클라우드 리소스를 피벗하고 트러스트 관계 또는 공유 비밀을 악용하여 손상된 VM에서 재사용된 토큰을 사용하여 Kubernetes 클러스터로 이동하는 등의 추가 시스템에 액세스할 수 있습니다.

MITRE ATT&CK

• 초기 액세스(TA0001): 공개 리포지토리 또는 잘못 구성된 스토리지의 API 키 또는 서비스 주체 토큰과 같은 노출된 자격 증명을 악용하여 공격자가 클라우드 리소스(예: T1078 - 유효한 계정)에 무단으로 진입할 수 있도록 합니다.
• 권한 상승(TA0004): 도난당한, 권한이 초과된 비밀을 사용하여 액세스 권한을 상승하여 공격자가 추가 리소스 또는 구독(예: T1078 - 유효한 계정)을 제어할 수 있습니다.
• 수집(TA0009): 노출된 데이터베이스 연결 문자열 또는 스토리지 키를 활용하여 중요한 데이터를 수집하여 클라우드 리소스에서 무단 데이터 추출(예: T1530 - Cloud Storage의 데이터)을 생성합니다.
• TA0008(횡적 이동): 상호 연결된 시스템 또는 가상 네트워크(예: T1021 - 원격 서비스)에 액세스하기 위해 재사용된 토큰 또는 서비스 계정과 같은 손상된 자격 증명을 사용하여 클라우드 리소스를 피벗합니다.

IM-8.1 라이브 비밀 및 자격 증명 검색

능동적인 비밀 탐지는 공격자가 발견하기 전에 소스 코드, 구성 파일, 통신 도구, 보관된 자료에 포함된 실시간 비밀을 식별하여 자격 증명의 노출을 방지합니다. 개발 파이프라인, 인프라 배포 및 스토리지 시스템에서 지속적인 비밀 검사를 구현하는 조직은 API 키, 연결 문자열 및 인증 토큰을 포함하여 노출된 자격 증명을 검색하고 수정합니다. CI/CD 워크플로에 통합된 자동화된 검색을 사용하면 자격 증명 누출에 신속하게 대응하여 노출 기간을 줄이고 클라우드 리소스 및 서비스에 대한 무단 액세스를 방지할 수 있습니다.

다음 방법을 통해 비밀 검색을 구현합니다.

• Azure DevOps 비밀 검사를 사용하도록 설정합니다. 코드 관리에 Azure DevOps를 사용하는 경우 Azure DevOps 자격 증명 스캐너를 구현하여 코드 리포지토리 내에서 자격 증명을 식별합니다.

• GitHub 비밀 검사를 사용하도록 설정합니다. GitHub 리포지토리의 경우 네이 티브 비밀 검사 기능을 사용하여 코드 내에서 자격 증명 또는 다른 형태의 비밀을 식별합니다.

• 에이전트 없는 비밀 검사 배포: VM, 스토리지 및 다중 클라우드 인스턴스에서 에이전트 없는 비밀 검색을 위해 클라우드용 Microsoft Defender를 사용하도록 설정하여 구성 파일 및 소스 코드 리포지토리의 연결 문자열과 같은 비밀을 검색합니다.

IM-8.2 비밀 및 자격 증명 보호

비밀의 안전한 관리는 중앙 집중식 보관소, 자동 갱신 및 접근 제어를 통해 인증 자격 증명을 보호하여 자격 증명 도난 및 무단 서비스 접근을 방지합니다. Azure Key Vault는 지원되는 서비스, HSM(하드웨어 보안 모듈) 지원 및 포괄적인 감사 로깅을 위한 기본 제공 회전 기능을 갖춘 엔터프라이즈급 비밀 스토리지를 제공합니다. 관리 ID를 통해 액세스하는 Key Vault에 비밀을 저장하는 조직은 하드 코딩된 자격 증명을 제거하고, 자동 회전 정책을 구현하며, 보안 프레임워크를 준수하면서 클라우드 및 하이브리드 환경에서 보안 서비스 간 인증을 사용하도록 설정합니다.

다음 방법을 사용하여 비밀 및 자격 증명을 보호합니다.

• Azure Key Vault에 비밀 저장: 관리 ID가 옵션이 아닌 경우 비밀 및 자격 증명을 코드 및 구성 파일에 포함하는 대신 Azure Key Vault와 같은 보안 위치에 저장해야 합니다.

• 자동 비밀 회전 구현: Azure Key Vault는 지원되는 서비스에 대한 자동 회전을 제공합니다. 자동으로 회전할 수 없는 비밀의 경우 수동으로 순환하고 더 이상 사용하지 않을 때 제거해야 합니다.

• 관리 ID를 통해 Key Vault에 액세스: Azure Functions, Azure Apps 서비스 및 VM과 같은 클라이언트는 관리 ID를 사용하여 추가 자격 증명을 저장하지 않고도 Azure Key Vault에 안전하게 액세스할 수 있습니다.

구현 예제

시나리오: 여러 팀의 개발자가 있는 핀테크 스타트업은 공용 GitHub 리포지토리에 커밋된 API 키가 고객 데이터를 노출하여 규제 벌금이 부과될 때 보안 인시던트를 경험합니다. 향후 자격 증명 누출을 방지하기 위해 포괄적인 비밀 검색 및 보호가 필요합니다.

1단계: 비밀 검색 - 자격 증명 누출 방지(IM-8.1)

1. 보안 애플리케이션 수명 주기에서 CredScan 구현:

   • CredScan을 Azure DevOps 파이프라인에 통합하여 일반적인 비밀 패턴을 검색합니다.
   • 심각도가 높은 비밀이 검색되어 프로덕션 배포를 차단하는 경우 실패하도록 파이프라인 구성
   • 초기 검사는 리포지토리(스토리지 키, SQL 연결 문자열, API 키, JWT 서명 비밀)에서 노출된 비밀을 식별합니다.

2. GitHub 고급 보안 비밀 검사:

   • 모든 리포지토리에 GitHub 고급 보안 사용
   • 일반적인 토큰 형식 및 사용자 지정 패턴을 검색하도록 네이티브 비밀 검색 구성
   • 푸시가 완료되기 전에 비밀이 포함된 커밋을 차단하도록 푸시 보호 사용
   • 인시던트 대응 워크플로를 트리거하도록 경고 설정

3. 클라우드를 위한 Microsoft Defender 에이전트가 없는 스캐닝:

   • Azure VM, 스토리지 계정 및 컨테이너 레지스트리용 Defender for Cloud 사용
   • 구성 파일, 컨테이너 이미지 및 Blob Storage에 대한 에이전트 없는 비밀 검사 구성
   • 실행 중인 VM, 스토리지 계정 및 컨테이너 이미지에서 발견된 비밀에 대한 자동화된 경고 설정

4. 기록 리포지토리 검사(수정):

   • Gitleaks 또는 TruffleHog와 같은 도구를 사용하여 전체 Git 기록에서 노출된 비밀을 검색합니다.
   • 시간이 지남에 따라 커밋에 노출되는 자격 증명 식별
   • 수정 구현: 식별된 모든 자격 증명 회전, Git 기록에서 비밀 제거, 개발자 교육

2단계: 기밀 보호 - 중앙 집중식 금고 및 회전(IM-8.2)

1. Azure Key Vault 배포:

   • 환경별 3개의 Key Vault 만들기(프로덕션, 스테이징, 개발)
   • 비밀 마이그레이션: 데이터베이스 연결 문자열, 타사 API 키, Azure 서비스 자격 증명, OAuth 비밀, 암호화 키
   • Azure SDK(.NET용 Azure.Security.KeyVault.Secrets, Node.js, @azure/keyvault-secrets Python용 azure-keyvault-secrets)를 사용하여 비밀을 검색하도록 마이크로 서비스를 업데이트합니다.
   • 코드, 구성 파일 및 CI/CD 파이프라인에서 하드 코딩된 모든 비밀 제거

2. 자동화된 비밀 회전:

   • Azure Storage 키, SQL 암호 및 서비스 주체 비밀에 대해 자동 회전 사용
   • 타사 API 키 및 데이터베이스 자격 증명에 대한 사용자 지정 회전 구현
   • 애플리케이션 및 운영자에 대한 최소 권한 액세스 권한으로 Key Vault RBAC 구성
   • 비정상적인 액세스 패턴에 대한 감사 로깅 및 경고 사용

3. 개발자 워크플로 및 인시던트 대응:

   • 학습 업데이트, 코드 템플릿 제공, 비밀 검색을 위한 사전 커밋 후크 적용
   • 파이프라인 비밀을 Key Vault 참조로 바꾸고, 서비스 연결에 관리 ID 사용
   • 명확한 에스컬레이션 경로 및 회전 프로시저를 사용하여 인시던트 응답 플레이북 정의

4. 연속 모니터링:

   • Key Vault 외부에 비밀이 확실히 존재하지 않도록 정기적으로 비밀 확산 검사를 수행합니다.
   • 비밀 만료 및 회전 준수에 대한 대시보드 추적
   • 정기적인 침투 테스트 및 보안 감사

결과:

조직은 코드베이스 및 인프라에서 노출된 모든 자격 증명을 성공적으로 식별하고 수정했습니다. Azure Key Vault로 포괄적인 마이그레이션을 통해 하드 코딩된 비밀이 프로덕션 코드에서 완전히 제거되었습니다. 자동화된 비밀 회전은 수동 오버헤드 및 사용자 오류를 크게 줄이면서 잠재적인 자격 증명 누출에 대한 검색 및 대응을 크게 단축합니다. 이 구현으로 인해 노출된 자격 증명에서 보안 인시던트가 발생하지 않고, 간소화된 비밀 관리 워크플로를 통해 개발자 생산성이 향상되었으며, SOC 2 및 PCI-DSS 표준을 비롯한 모든 보안 감사 요구 사항을 완전히 준수하게 됩니다.

참조::

• 보안 애플리케이션 수명 주기 - 1부 - CredScan 사용
• Azure Key Vault를 사용하여 비밀 관리
• Key Vault에서 비밀 회전 자동화

중요도 수준

있어야 합니다.

컨트롤 매핑

• NIST SP 800-53 Rev.5: IA-5, SI-4, RA-5, SC-12, SC-13, SC-28
• PCI-DSS v4: 3.5.1, 6.3.2, 8.2.1, 8.3.2
• CIS 컨트롤 v8.1: 16.9, 16.10, 16.12
• NIST CSF v2.0: DE.CM-8, PR.DS-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.8.3, A.8.24
• SOC 2: CC6.1, CC6.6, CC7.2