ID 및 액세스 관리에 대한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.

SE:05 모든 워크로드 사용자, 팀 구성원 및 시스템 구성 요소에서 엄격하고 조건부이며 감사 가능한 IAM(ID 및 액세스 관리)을 구현합니다. 필요에 따라 액세스를 로만 제한합니다. 모든 인증 및 권한 부여 구현에 최신 산업 표준을 사용합니다. ID를 기반으로 하지 않는 액세스를 제한하고 엄격하게 감사합니다.

이 가이드에서는 워크로드 리소스에 액세스하려는 ID를 인증하고 권한을 부여하기 위한 권장 사항을 설명합니다.

기술 제어 관점에서 ID는 항상 기본 경계입니다. 이 scope 워크로드의 에지를 포함하지 않습니다. 워크로드 내에 있는 개별 구성 요소도 포함됩니다. 일반적인 ID는 다음과 같습니다.

  • 인간. 애플리케이션 사용자, 관리자, 운영자, 감사자 및 잘못된 행위자.

  • 시스템. 워크로드 ID, 관리 ID, API 키, 서비스 주체 및 Azure 리소스.

  • 익명. 그들이 누구인지에 대한 증거를 제공하지 않은 엔터티.

정의 

사용 약관 정의
인증(AuthN) ID가 누구인지 또는 무엇이라고 말하는지 확인하는 프로세스입니다.
권한 부여(AuthZ) ID에 요청된 작업을 수행할 수 있는 권한이 있는지 여부를 확인하는 프로세스입니다.
조건부 액세스 지정된 조건에 따라 작업을 허용하는 규칙 집합입니다.
IdP ID 공급자(예: Microsoft Entra ID)
가상 사용자 작업 함수 또는 책임 및 작업 집합이 있는 타이틀입니다.
미리 공유된 키 공급자와 소비자 간에 공유되고 안전하고 합의된 메커니즘을 통해 사용되는 비밀 유형입니다.
리소스 ID 플랫폼에서 관리하는 클라우드 리소스에 대해 정의된 ID입니다.
역할 사용자 또는 그룹이 수행할 수 있는 작업을 정의하는 권한 집합입니다.
범위 역할이 작동하도록 허용되는 다양한 수준의 조직 계층 구조입니다. 또한 시스템의 기능 그룹입니다.
할당할 수 있습니다. 사용 권한을 제공하는 ID입니다. 사용자, 그룹 또는 서비스 주체일 수 있습니다. 모든 그룹 구성원은 동일한 수준의 액세스 권한을 얻습니다.
사용자 ID 직원 또는 외부 사용자와 같은 사람의 ID입니다.
워크로드 ID 다른 서비스 및 리소스에 인증하는 데 사용되는 워크로드의 애플리케이션, 서비스, 스크립트, 컨테이너 또는 기타 구성 요소에 대한 시스템 ID입니다.

참고

ID는 보안 주체라는 부모 아래에서 유사한 다른 ID와 그룹화할 수 있습니다. 보안 그룹은 보안 주체의 예입니다. 이 계층적 관계는 유지 관리를 간소화하고 일관성을 개선합니다. ID 특성은 개별 수준에서 처리되지 않으므로 오류 가능성도 줄어듭니다. 이 문서에서 ID 라는 용어는 보안 주체를 포함합니다.

ID 공급자의 역할

IdP(ID 공급자)는 사용자를 디지털 ID로 저장하고 관리하는 클라우드 호스팅 서비스입니다.

ID 및 액세스 관리를 위해 신뢰할 수 있는 IdP에서 제공하는 기능을 활용합니다. IdP를 대체할 사용자 지정 시스템을 구현하지 마세요. IdP 시스템은 매일 여러 테넌트에서 수십억 개의 신호를 캡처하여 최신 공격 벡터를 기반으로 자주 개선됩니다. Microsoft Entra ID는 Azure 클라우드 플랫폼용 IdP입니다.

인증

인증은 ID를 확인하는 프로세스입니다. 확인 가능한 식별 형식을 제공하려면 요청 ID가 필요합니다. 예를 들면 다음과 같습니다.

  • 사용자 이름 및 암호입니다.

  • 액세스 권한을 부여하는 API 키와 같은 미리 공유된 비밀입니다.

  • SAS(공유 액세스 서명) 토큰입니다.

  • TLS 상호 인증에 사용되는 인증서입니다.

IdP에서 확인 프로세스를 최대한 처리해야 합니다.

권한 부여

권한 부여는 확인된 ID에서 요청한 작업을 허용하거나 거부하는 프로세스입니다. 작업은 운영 또는 리소스 관리와 관련될 수 있습니다.

권한 부여를 사용하려면 IdP에서 제공하는 기능을 사용하여 수행해야 하는 ID에 권한을 할당해야 합니다.

주요 디자인 전략

워크로드에 필요한 ID의 전체적인 보기를 얻으려면 흐름, 워크로드 자산 및 가상 사용자와 자산 및 가상 사용자가 수행할 작업을 카탈로그화해야 합니다. 전략은 워크로드 또는 해당 구성 요소(외부 액세스)에 도달하는 흐름과 워크로드에서 다른 원본으로 도달하는 흐름(내부 액세스)을 처리하는 모든 사용 사례를 포함해야 합니다.

각 사용 사례에는 위반 가정 사고방식으로 디자인해야 하는 자체 컨트롤 집합이 있을 수 있습니다. 사용 사례 또는 가상 사용자의 ID 요구 사항에 따라 조건부 선택을 식별합니다. 모든 사용 사례에 대해 하나의 솔루션을 사용하지 않도록 합니다. 반대로 컨트롤이 너무 세분화되어 불필요한 관리 오버헤드가 발생해서는 안 됩니다.

ID 액세스 내역을 기록해야 합니다. 이렇게 하면 컨트롤의 유효성을 검사하는 데 도움이 되며 규정 준수 감사에 로그를 사용할 수 있습니다.

인증에 대한 모든 ID 확인

  • 아웃사이드 인 액세스. ID 디자인은 다양한 용도로 워크로드에 액세스하는 모든 사용자를 인증해야 합니다. 예를 들어 API를 호출하여 애플리케이션에 액세스하는 최종 사용자입니다.

    세분화된 수준에서 워크로드의 구성 요소는 외부에서 액세스해야 할 수도 있습니다. 예를 들어 포털을 통해 액세스하거나 명령을 실행하기 위해 컴퓨팅에 액세스해야 하는 연산자입니다.

    둘 다 가상 사용자가 다른 사용자 ID 의 예입니다.

  • 인사이드 아웃 액세스. 애플리케이션은 다른 리소스에 액세스해야 합니다. 예를 들어 데이터 플랫폼에서 읽거나 쓰고, 비밀 저장소에서 비밀을 검색하고, 원격 분석을 모니터링 서비스에 로깅합니다. 타사 서비스에 액세스해야 할 수도 있습니다. 이러한 액세스 요구 사항에는 워크로드 ID가 필요하며, 이를 통해 애플리케이션은 다른 리소스에 대해 인증할 수 있습니다.

    개념은 구성 요소 수준에서 적용됩니다. 다음 예제에서는 컨테이너가 구성을 가져오기 위해 배포 파이프라인에 액세스해야 할 수 있습니다. 이러한 액세스에는 리소스 ID가 필요합니다.

이러한 모든 ID는 IdP에서 인증해야 합니다.

아키텍처에서 ID를 구현하는 방법의 예는 다음과 같습니다.

아키텍처에서 ID를 구현하는 방법을 보여 주는 다이어그램

권한 부여에 대한 작업 확인

다음으로, 인증된 각 ID가 어떤 작업을 수행하려고 하는지 알고 있어야 해당 작업에 권한을 부여할 수 있습니다. 작업은 필요한 액세스 유형으로 나눌 수 있습니다.

  • 데이터 평면 액세스. 데이터 평면에서 발생하는 작업으로 인해 내부 또는 외부 액세스에 대한 데이터 전송이 발생합니다. 예를 들어 애플리케이션은 데이터베이스에서 데이터를 읽고 데이터베이스에 데이터를 쓰거나, 비밀을 가져오거나, 모니터링 싱크에 로그를 작성합니다. 구성 요소 수준에서 레지스트리에서 이미지를 끌어 오가거나 푸시하는 컴퓨팅은 데이터 평면 작업으로 간주됩니다.

  • 컨트롤 플레인 액세스. 컨트롤 플레인에서 발생하는 작업으로 인해 Azure 리소스가 생성, 수정 또는 삭제됩니다. 예를 들어 리소스 속성에 대한 변경 내용입니다.

애플리케이션은 일반적으로 데이터 평면 작업을 대상으로 하지만 작업은 제어 평면과 데이터 평면 모두에 액세스하는 경우가 많습니다. 권한 부여 요구 사항을 식별하려면 리소스에서 수행할 수 있는 운영 작업을 확인합니다. 각 리소스에 대해 허용되는 작업에 대한 자세한 내용은 Azure 리소스 공급자 작업을 참조하세요.

역할 기반 권한 부여 제공

각 ID의 책임에 따라 허용해야 하는 작업에 권한을 부여합니다. ID가 필요한 것보다 더 많은 작업을 수행하도록 허용해서는 안 됩니다. 권한 부여 규칙을 설정하기 전에 누가 또는 무엇을 요청하는지, 해당 역할이 수행할 수 있는 작업 및 수행할 수 있는 범위를 명확하게 이해해야 합니다. 이러한 요인은 ID, 역할 및 scope 결합하는 선택으로 이어지고 있습니다.

워크로드 ID를 예로 들어 보세요. 애플리케이션은 데이터베이스에 대한 데이터 평면 액세스 권한이 있어야 하므로 데이터 리소스에 대한 읽기 및 쓰기 작업을 허용해야 합니다. 그러나 애플리케이션에 비밀 저장소에 대한 컨트롤 플레인 액세스가 필요한가요? 잘못된 행위자가 워크로드 ID를 손상하는 경우 기밀성, 무결성 및 가용성 측면에서 시스템에 미치는 영향은 무엇인가요?

역할 할당

역할은 ID에 할당된 권한 집합 입니다. ID만 작업을 완료하도록 허용하는 역할을 할당하고 더 이상 작업을 완료하지 않습니다. 사용자의 권한이 작업 요구 사항으로 제한되면 시스템에서 의심스럽거나 권한 없는 동작을 쉽게 식별할 수 있습니다.

다음과 같은 질문을 하세요.

  • 읽기 전용 액세스가 충분합니까?
  • ID에 리소스를 삭제할 수 있는 권한이 필요한가요?

사용자, 애플리케이션 또는 서비스가 Azure 리소스에 액세스하는 수준을 제한하면 잠재적인 공격 노출 영역이 줄어듭니다. 특정 작업을 수행하는 데 필요한 최소 권한만 부여하면 공격 성공 또는 무단 액세스의 위험이 크게 줄어듭니다. 예를 들어 보안 팀은 모든 기술 환경에 대한 보안 특성에 대한 읽기 전용 액세스만 필요합니다. 해당 수준은 위험 요소를 평가하고, 잠재적 완화를 식별하고, 위험을 보고하기에 충분합니다.

조직 구조 및 팀 organization 인해 사용자에게 더 많은 액세스 권한이 필요한 시나리오가 있습니다. 다양한 역할 간에 겹치거나 단일 사용자가 여러 표준 역할을 수행할 수 있습니다. 이 경우 이러한 각 사용자에 대한 사용자 지정 역할을 만드는 대신 비즈니스 기능을 기반으로 하는 여러 역할 할당을 사용합니다. 이렇게 하면 역할을 더 쉽게 관리할 수 있습니다.

개별 리소스 또는 사용자를 구체적으로 참조하는 권한은 피합니다. 세분화된 사용자 지정 권한은 유사한 새 리소스에 의도를 전달하지 않으므로 복잡성과 혼란을 야기합니다. 이렇게 하면 유지 관리가 어렵고 보안과 안정성 모두에 부정적인 영향을 주는 복잡한 레거시 구성을 만들 수 있습니다.

절충: 세분화된 액세스 제어 접근 방식을 사용하면 사용자 활동을 더 잘 감사하고 모니터링할 수 있습니다.

역할에는 연결된 scope 있습니다. 역할은 허용된 관리 그룹, 구독, 리소스 그룹 또는 리소스 scope 또는 다른 사용자 지정 scope 작동할 수 있습니다. ID에 제한된 사용 권한 집합이 있더라도 id의 작업 기능 외부에 있는 리소스를 포함하도록 scope 확대하는 것은 위험합니다. 예를 들어 모든 소스 코드 및 데이터에 대한 읽기 액세스는 위험할 수 있으며 제어해야 합니다.

RBAC(역할 기반 액세스 제어)를 사용하여 ID에 역할을 할당합니다. 항상 IdP 제공 RBAC를 사용하여 액세스 제어를 일관되게 적용하고 엄격하게 취소할 수 있는 기능을 활용합니다.

기본 제공 역할을 사용합니다. 대부분의 사용 사례를 포함하도록 설계되었습니다. 사용자 지정 역할은 강력하고 때로는 유용하지만 기본 제공 역할이 작동하지 않는 시나리오에 대해 예약해야 합니다. 사용자 지정은 복잡성을 유발하여 혼란을 가중시키고 자동화를 더 복잡하고 어렵고 취약하게 만듭니다. 이러한 요인은 모두 보안에 부정적인 영향을 줍니다.

최소 권한으로 시작하고 운영 또는 데이터 액세스 요구 사항에 따라 더 많은 역할을 추가합니다. 기술 팀은 사용 권한을 구현하기 위한 명확한 지침이 있어야 합니다.

RBAC에 대한 세분화된 제어를 원하는 경우 작업 및 특성과 같은 컨텍스트에 따라 역할 할당에 대한 조건을 추가합니다.

조건부 액세스 선택

모든 ID에 동일한 수준의 액세스 권한을 부여하지 마세요. 다음 두 가지 기본 요인에 따라 결정합니다.

  • 시간. ID가 환경에 액세스할 수 있는 기간입니다.

  • 권한. 사용 권한 수준입니다.

이러한 요소는 상호 배타적이지 않습니다. 더 많은 권한과 무제한 액세스 기간을 가진 손상된 ID는 시스템 및 데이터를 더 많이 제어하거나 해당 액세스를 사용하여 환경을 계속 변경할 수 있습니다. 이러한 액세스 요소를 예방 조치로 제한하고 폭발 반경을 제어합니다.

  • JIT(Just In Time) 접근 방식은 필요한 경우에만 필요한 권한을 제공합니다.

  • JEA(Just Enough Access) 는 필요한 권한만 제공합니다.

시간과 권한이 주요 요소이지만 다른 조건이 적용됩니다. 예를 들어 액세스가 시작된 디바이스, 네트워크 및 위치를 사용하여 정책을 설정할 수도 있습니다.

사용자 ID 및 위치, 디바이스 상태, 워크로드 컨텍스트, 데이터 분류 및 변칙과 같은 매개 변수를 포함하여 권한 없는 액세스를 필터링, 검색 및 차단하는 강력한 컨트롤을 사용합니다.

예를 들어 공급업체, 파트너 및 고객과 같은 타사 ID에서 워크로드에 액세스해야 할 수 있습니다. 정규직 직원에게 제공하는 기본 권한보다는 적절한 수준의 액세스가 필요합니다. 외부 계정을 명확하게 구분하면 이러한 벡터에서 발생하는 공격을 더 쉽게 방지하고 검색할 수 있습니다.

IdP의 선택은 이러한 차별화를 제공하고, 최소 권한에 따라 권한을 부여하는 기본 제공 기능을 제공하고, 기본 제공 위협 인텔리전스를 제공할 수 있어야 합니다. 여기에는 액세스 요청 및 로그인 모니터링이 포함됩니다. Azure IdP는 Microsoft Entra ID입니다. 자세한 내용은 이 문서의 Azure 촉진 섹션 을 참조하세요.

중요한 영향 계정

관리 ID는 수행하는 작업에 이러한 시스템 및 애플리케이션의 광범위한 집합에 대한 권한 있는 액세스가 필요하기 때문에 가장 큰 영향을 미치는 보안 위험 중 일부를 도입합니다. 손상 또는 오용은 비즈니스 및 해당 정보 시스템에 해로운 영향을 미칠 수 있습니다. 관리 보안은 가장 중요한 보안 영역 중 하나입니다.

확인된 악의적 사용자로부터 권한 있는 액세스를 보호하려면 이러한 시스템을 위험으로부터 격리하기 위한 완전하고 신중한 접근 방식을 취해야 합니다. 다음은 몇 가지 전략입니다.

  • 중요한 영향 계정 수를 최소화합니다.

  • 기존 ID에 대한 권한을 높이는 대신 별도의 역할을 사용합니다.

  • IdP의 JIT 기능을 사용하여 영구 액세스 또는 고정 액세스를 방지합니다. 비상 사태의 경우 긴급 액세스 프로세스를 따르세요.

  • 암호 없는 인증 또는 다단계 인증과 같은 최신 액세스 프로토콜을 사용합니다. 이러한 메커니즘을 IdP에 외부화합니다.

  • 조건부 액세스 정책을 사용하여 주요 보안 특성을 적용합니다.

  • 사용되지 않는 관리 계정의 서비스 해제

환경 전체에서 단일 ID를 사용하고 단일 ID를 사용자 또는 보안 주체와 연결합니다. 클라우드 및 온-프레미스 환경에서 ID의 일관성은 사람의 오류와 그로 인한 보안 위험을 줄입니다. 리소스를 관리하는 두 환경의 팀은 보안 보증을 충족하기 위해 일관되고 신뢰할 수 있는 원본이 필요합니다. 중앙 ID 팀과 협력하여 하이브리드 환경의 ID가 동기화되었는지 확인합니다.

위험: 높은 권한 ID 동기화와 관련된 위험이 있습니다. 공격자는 온-프레미스 자산을 완전히 제어할 수 있으며 이로 인해 클라우드 계정이 성공적으로 손상 될 수 있습니다. 공격 화면에 추가할 수 있는 계정을 필터링하여 동기화 전략을 평가합니다.

ID 수명 주기를 관리하는 프로세스 설정

ID에 대한 액세스는 ID가 액세스하는 리소스보다 오래 지속되지 않아야 합니다. 팀 구조 또는 소프트웨어 구성 요소가 변경될 때 ID를 사용하지 않도록 설정하거나 삭제하는 프로세스가 있는지 확인합니다.

이 지침은 소스 제어, 데이터, 컨트롤 플레인, 워크로드 사용자, 인프라, 도구, 데이터 모니터링, 로그, 메트릭 및 기타 엔터티에 적용됩니다.

디지털 ID, 높은 권한의 사용자, 외부/게스트 사용자 및 워크로드 사용자의 수명 주기를 관리하는 ID 거버넌스 프로세스를 설정합니다. 액세스 검토를 구현하여 ID가 organization 또는 팀을 떠날 때 워크로드 권한이 제거되도록 합니다.

비identity 기반 비밀 보호

미리 공유된 키와 같은 애플리케이션 비밀은 시스템에서 취약한 지점으로 간주되어야 합니다. 양방향 통신에서 공급자 또는 소비자가 손상된 경우 상당한 보안 위험이 발생할 수 있습니다. 이러한 키는 운영 프로세스를 도입하기 때문에 부담이 될 수도 있습니다.

가능한 경우 비밀을 사용하지 말고 리소스뿐만 아니라 애플리케이션 자체에 대한 사용자 액세스에 ID 기반 인증을 사용하는 것이 좋습니다.

다음 목록에서는 지침의 요약을 제공합니다. 자세한 내용은 애플리케이션 비밀에 대한 권장 사항을 참조하세요.

  • 이러한 비밀을 비밀 저장소에서 동적으로 가져올 수 있는 엔터티로 처리합니다. 애플리케이션 코드, IaC 스크립트, 배포 파이프라인 또는 다른 아티팩트에서 하드 코딩해서는 안 됩니다.

  • 비밀을 해지할 수 있는지 확인합니다.

  • 키 회전 및 만료와 같은 작업을 처리하는 운영 사례를 적용합니다.

회전 정책에 대한 자세한 내용은 인증 자격 증명의 두 집합이 있는 리소스에 대한 비밀 회전 자동화 및 자습서: Key Vault 인증서 자동 회전 빈도 업데이트를 참조하세요.

개발 환경을 안전하게 유지

모든 코드 및 스크립트, 파이프라인 도구 및 소스 제어 시스템을 워크로드 자산으로 간주해야 합니다. 쓰기에 대한 액세스는 자동화 및 피어 검토를 통해 제어되어야 합니다. 소스 코드에 대한 읽기 액세스 는 알아야 할 기준으로 역할로 제한되어야 합니다. 코드 리포지토리에는 버전 관리가 있어야 하며 피어의 보안 코드 검토 는 개발 수명 주기와 통합된 정기적인 관행이어야 합니다. 리소스를 정기적으로 검사하고 최신 취약성을 식별하는 프로세스가 있어야 합니다.

워크로드 ID를 사용하여 GitHub와 같은 배포 환경에서 리소스에 대한 액세스 권한을 부여합니다.

감사 내역 유지 관리

ID 관리의 한 가지 측면은 시스템을 감사할 수 있도록 하는 것입니다. 감사는 위반 가정 전략이 효과적인지 여부를 확인합니다. 감사 내역을 유지 관리하면 다음을 수행할 수 있습니다.

  • ID가 강력한 인증으로 인증되었는지 확인합니다. 거부 공격을 방지하려면 모든 작업을 추적할 수 있어야 합니다.

  • 약하거나 누락된 인증 프로토콜을 검색 하고 사용자 및 애플리케이션 로그인에 대한 가시성과 인사이트를 얻습니다.

  • 보안 및 규정 준수 요구 사항에 따라 ID에서 워크로드로의 액세스를 평가하고 사용자 계정 위험, 디바이스 상태 및 설정한 기타 기준 및 정책을 고려합니다.

  • 규정 준수 요구 사항에서 진행률 또는 편차를 추적합니다.

대부분의 리소스에는 데이터 평면 액세스 권한이 있습니다. 리소스에 액세스하는 ID와 리소스가 수행하는 작업을 알아야 합니다. 보안 진단 해당 정보를 사용할 수 있습니다.

자세한 내용은 보안 모니터링 및 위협 분석에 대한 권장 사항을 참조하세요.

Azure 촉진

항상 사용 가능한 모든 데이터 요소를 고려하여 조건부 액세스를 사용하는 최신 인증 프로토콜을 사용하는 것이 좋습니다. Microsoft Entra ID는 Azure에서 ID 및 액세스 관리를 제공합니다. Azure의 관리 평면을 다루며 대부분의 Azure 서비스의 데이터 평면과 통합됩니다. Microsoft Entra ID는 워크로드 구독과 연결된 테넌트입니다. ID 및 허용된 권한을 추적하고 관리하며 감독 또는 인적 오류의 위험을 최소화하기 위해 전체 관리를 간소화합니다.

이러한 기능은 기본적으로 사용자 세그먼트에 대해 동일한 Microsoft Entra ID 및 권한 모델에 통합됩니다.

MSAL(Microsoft 인증 라이브러리) 또는 플랫폼 기능(예: 웹앱 인증)을 통해 사용자 지정 애플리케이션의 인증 및 권한 부여에 Microsoft Entra ID를 사용할 수 있습니다. Azure의 관리 평면, 대부분의 Azure 서비스의 데이터 평면 및 애플리케이션에 대한 통합 기능을 다룹니다.

Microsoft Entra ID의 새로운 기능을 방문하여 최신 상태를 유지할 수 있습니다.

절충: Microsof Microsoft Entra ID는 다른 기본 서비스와 마찬가지로 단일 실패 지점입니다. Microsoft에서 중단을 수정하기 전까지는 해결 방법이 없습니다. 그러나 Microsoft Entra 풍부한 기능 집합은 사용자 지정 솔루션을 사용할 위험보다 큽니다.

Azure는 OAuth2 및 OpenID Connect와 같은 개방형 프로토콜을 지원합니다. 사용자 고유의 흐름을 디자인하는 대신 이러한 표준 인증 및 권한 부여 메커니즘을 사용하는 것이 좋습니다.

Azure RBAC

Azure RBAC는 Microsoft Entra ID의 보안 주체를 나타냅니다. 모든 역할 할당은 Azure RBAC를 통해 수행됩니다. 필요한 대부분의 권한을 제공하는 기본 제공 역할을 활용합니다. 자세한 내용은 Microsoft Entra 기본 제공 역할을 참조하세요.

다음은 몇 가지 사용 사례입니다.

RBAC에 대한 자세한 내용은 Azure RBAC 모범 사례를 참조하세요.

특성 기반 컨트롤에 대한 자세한 내용은 Azure ABAC란?을 참조하세요.

워크로드 ID

Microsoft Entra ID는 애플리케이션의 ID를 처리할 수 있습니다. 애플리케이션과 연결된 서비스 주체는 액세스 scope 지시할 수 있습니다.

자세한 내용은 워크로드 ID란?을 참조하세요.

관리 ID를 사용하는 경우에도 서비스 주체가 추상화됩니다. 장점은 Azure가 애플리케이션에 대한 모든 자격 증명을 관리한다는 것입니다.

모든 서비스가 관리 ID를 지원하는 것은 아닙니다. 관리 ID를 사용할 수 없는 경우 서비스 주체를 사용할 수 있습니다. 그러나 서비스 주체를 사용하면 관리 오버헤드가 증가합니다. 자세한 내용은 Azure 리소스에 대한 관리 ID란?을 참조하세요.

리소스 ID

관리 ID의 개념은 Azure 리소스로 확장할 수 있습니다. Azure 리소스는 관리 ID를 사용하여 Microsoft Entra 인증을 지원하는 다른 서비스에 인증할 수 있습니다. 자세한 내용은 관리 ID를 사용하여 다른 서비스에 액세스할 수 있는 Azure 서비스를 참조하세요.

조건부 액세스 정책

조건부 액세스는 액세스 결정에 대한 정책을 설명합니다. 조건부 액세스를 사용하려면 사용 사례에 필요한 제한을 이해해야 합니다. 운영 요구 사항에 따라 액세스 정책을 설정하여 Microsoft Entra 조건부 액세스를 구성합니다.

자세한 내용은 조건부 액세스: 사용자, 그룹 및 워크로드 ID를 참조하세요.

그룹 액세스 관리

특정 사용자에게 권한을 부여하는 대신 Microsoft Entra ID의 그룹에 대한 액세스 권한을 할당합니다. 그룹이 없는 경우 ID 팀과 협력하여 그룹을 만듭니다. 그런 다음, Azure 외부에서 그룹 멤버를 추가 및 제거하고 권한이 최신인지 확인할 수 있습니다. 메일 그룹 같은 다른 용도로 그룹을 사용할 수도 있습니다.

자세한 내용은 Microsoft Entra ID의 그룹을 사용하여 액세스 제어 보안을 참조하세요.

위협 탐지

Microsoft Entra ID Protection ID 기반 위험을 감지, 조사 및 수정하는 데 도움이 될 수 있습니다. 자세한 내용은 ID 보호란?을 참조하세요.

위협 탐지는 의심스러운 활동에 대한 경고에 대응하거나 활동 로그에서 비정상적인 이벤트를 사전에 검색하는 형식을 사용할 수 있습니다. Microsoft Sentinel의 UEBA(사용자 및 엔터티 동작 분석)를 사용하면 의심스러운 활동을 쉽게 검색할 수 있습니다. 자세한 내용은 UEBA를 사용하여 고급 위협 식별을 참조하세요.

하이브리드 시스템

Azure에서는 기존 Active Directory에서 높은 권한이 있는 Microsoft Entra ID에 계정을 동기화하지 마세요. 이 동기화는 기본 Microsoft Entra 동기화 연결 구성에서 차단되므로 이 구성을 사용자 지정하지 않았는지 확인하기만 하면 됩니다.

Microsoft Entra ID의 필터링에 대한 자세한 내용은 Microsoft Entra 연결 동기화: 필터링 구성을 참조하세요.

ID 로깅

Azure 리소스에서 진단 설정을 사용하도록 설정 하여 감사 내역으로 사용할 수 있는 정보를 내보낼 수 있습니다. 진단 정보는 어떤 ID가 어떤 리소스에 액세스하려고 하며 이러한 시도의 결과를 보여 줍니다. 수집된 로그는 Azure Monitor로 전송됩니다.

절충: 로깅은 로그를 저장하는 데 사용되는 데이터 스토리지로 인해 비용이 발생합니다. 특히 애플리케이션에 추가하는 코드 및 로깅 솔루션에 성능 영향을 줄 수도 있습니다.

예제

다음 예제에서는 ID 구현을 보여줍니다. 다양한 유형의 ID를 함께 사용하여 필요한 수준의 액세스를 제공합니다.

ID 구현을 보여 주는 다이어그램

ID 구성 요소

  • 시스템 관리 ID. Microsoft Entra ID는 Azure Key Vault 및 데이터 저장소와 같이 사용자를 마주하지 않는 서비스 데이터 평면에 대한 액세스를 제공합니다. 또한 이러한 ID는 RBAC를 통해 워크로드 구성 요소, 배포 에이전트 및 팀 구성원을 위한 Azure 관리 평면에 대한 액세스를 제어합니다.

  • 워크로드 ID. AKS(Azure Kubernetes Service) 클러스터의 애플리케이션 서비스는 워크로드 ID를 사용하여 솔루션의 다른 구성 요소에 인증합니다.

  • 관리 ID. 클라이언트 역할의 시스템 구성 요소는 빌드 에이전트를 포함하여 시스템 관리 ID를 사용합니다.

  • 인간의 정체성. 사용자 및 운영자 인증은 Microsoft Entra ID 또는 Microsoft Entra ID(네이티브, B2B 또는 B2C)에 위임됩니다.

사전 공유된 비밀의 보안은 모든 애플리케이션에 매우 중요합니다. Azure Key Vault Redis 및 타사 비밀을 포함하여 이러한 비밀에 대한 보안 스토리지 메커니즘을 제공합니다.

회전 메커니즘은 비밀이 손상되지 않도록 하는 데 사용됩니다. OAuth 2 및 OpenID Connect의 Microsoft ID 플랫폼 구현을 위한 토큰은 사용자를 인증하는 데 사용됩니다.

Azure Policy Key Vault 같은 ID 구성 요소가 액세스 정책 대신 RBAC를 사용하도록 하는 데 사용됩니다. JIT 및 JEA는 인간 운영자에게 기존의 상설 권한을 제공합니다.

액세스 로그는 Azure Diagnostics 통해 또는 코드 구성 요소에 대한 코드를 통해 모든 구성 요소에서 사용하도록 설정됩니다.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.

보안 검사 목록