온-프레미스 Active Directory Federation Services를 Azure로 확장
이 참조 아키텍처는 온-프레미스 네트워크를 Azure로 확장하고 AD FS(Active Directory Federation Services) 를 사용하여 Azure에서 실행되는 구성 요소에 대한 페더레이션 인증 및 권한 부여를 수행하는 보안 하이브리드 네트워크를 구현합니다.
Architecture
이 아키텍처의 Visio 파일을 다운로드합니다.
Workflow
다음 워크플로는 이전 다이어그램에 해당합니다.
AD DS(Active Directory Domain Services) 서브넷: AD DS 서버는 NSG(네트워크 보안 그룹) 규칙이 방화벽 역할을 하는 자체 서브넷에 포함됩니다.
AD DS 서버: Azure에서 VM(가상 머신)으로 실행되는 도메인 컨트롤러. 이러한 서버는 도메인 내에서 로컬 ID의 인증을 제공합니다.
AD FS 서브넷: AD FS 서버는 자체 서브넷 내에 있으며 NSG 규칙을 방화벽으로 사용합니다.
AD FS 서버: AD FS 서버는 페더레이션된 권한 부여 및 인증을 제공합니다. 이 아키텍처에서 다음 작업을 수행합니다.
파트너 사용자를 대신하여 파트너 페더레이션 서버에서 수행한 클레임이 포함된 보안 토큰을 받습니다. AD FS는 요청 권한을 부여하기 위해 Azure에서 실행되는 웹 애플리케이션에 클레임을 전달하기 전에 토큰이 유효한지 확인합니다.
Azure에서 실행되는 애플리케이션을 신뢰 당사자로 알려져 있습니다. 파트너 페더레이션 서버는 웹 애플리케이션이 이해하는 클레임을 발급해야 합니다. 파트너 페더레이션 서버는 파트너 조직에서 인증된 계정을 대신하여 액세스 요청을 제출하기 때문에 계정 파트너라고 합니다. AD FS 서버는 리소스(웹 애플리케이션)에 대한 액세스를 제공하기 때문에 리소스 파트너 라고 합니다.
AD DS 및 DRS(Active Directory 디바이스 등록 서비스)를 사용하여 웹 애플리케이션에 액세스해야 하는 웹 브라우저 또는 디바이스를 실행하는 외부 사용자의 들어오는 요청을 인증하고 권한을 부여합니다.
AD FS 서버는 Azure 부하 분산 장치를 통해 액세스되는 팜으로 구성됩니다. 이 구현은 가용성과 확장성을 향상시킵니다. AD FS 서버는 인터넷에 직접 노출되지 않습니다. 모든 인터넷 트래픽은 AD FS WAP(웹 애플리케이션 프록시) 서버와 경계 네트워크라고도 하는 DMZ(완만 영역)를 통해 필터링됩니다.
자세한 내용은 AD FS 개요를 참조하세요.
AD FS 프록시 서브넷: AD FS 프록시 서버는 자체 서브넷 내에 포함할 수 있으며 보호를 위해 NSG 규칙을 사용할 수 있습니다. 이 서브넷의 서버는 Azure 가상 네트워크와 인터넷 간에 방화벽을 제공하는 네트워크 가상 어플라이언스 집합을 통해 인터넷에 노출됩니다.
AD FS WAP 서버: 이러한 VM은 파트너 조직 및 외부 디바이스에서 들어오는 요청에 대한 AD FS 서버 역할을 합니다. WAP 서버는 인터넷에서 직접 액세스하지 못하도록 AD FS 서버를 보호하는 필터 역할을 합니다. AD FS 서버와 마찬가지로 부하 분산을 사용하여 팜에 WAP 서버를 배포하면 독립 실행형 서버 컬렉션을 배포하는 것보다 가용성과 확장성이 향상됩니다. 자세한 내용은 WAP 서버 설치 및 구성을 참조하세요.
파트너 조직: 파트너 조직은 Azure에서 실행되는 웹 애플리케이션에 대한 액세스를 요청하는 웹 애플리케이션을 실행합니다. 파트너 조직의 페더레이션 서버는 로컬로 요청을 인증하고 Azure에서 실행되는 AD FS에 대한 클레임이 포함된 보안 토큰을 제출합니다. Azure의 AD FS는 보안 토큰의 유효성을 검사합니다. 토큰이 유효한 경우 AD FS는 Azure에서 실행되는 웹 애플리케이션에 클레임을 전달하여 권한을 부여할 수 있습니다.
Note
Azure 게이트웨이를 사용하여 신뢰할 수 있는 파트너에 대한 AD FS에 대한 직접 액세스를 제공하여 VPN 터널을 구성할 수도 있습니다. 이러한 파트너로부터 받은 요청은 WAP 서버를 통과하지 않습니다.
Components
이 아키텍처는 Azure 가상 네트워크의 AD DS 배포에 설명된 구현을 확장합니다. 여기에는 다음 구성 요소가 포함됩니다.
AD DS 서브넷은 IP 주소 범위를 사이트에 매핑하는 개체입니다. 이 매핑을 사용하면 도메인 컨트롤러가 클라이언트의 네트워크 위치에 따라 인증 및 복제를 효율적으로 지시할 수 있습니다.
AD DS 서버 는 Active Directory Domain Services를 호스트하는 도메인 컨트롤러입니다. 엔터프라이즈 네트워크에서 중앙 집중식 인증, 정책 적용 및 디렉터리 데이터 복제를 제공합니다.
AD FS 서브넷은 AD FS 서버 또는 WAP 서버를 호스트하는 네트워크 또는 가상 인프라 내에서 정의된 IP 주소 범위입니다. 이 IP 주소 범위를 사용하면 보안 트래픽 흐름 및 사이트 인식 인증을 사용할 수 있습니다.
AD FS 서버 는 클레임 기반 ID 프로토콜을 사용하여 보안 토큰을 발급하고 인증 요청을 처리하는 내부 페더레이션 서버입니다.
AD FS 프록시 서브넷 은 WAP 서버를 호스트하는 네트워크 세그먼트(일반적으로 DMZ)입니다. 외부 인증 트래픽을 내부 AD FS 서버로 안전하게 릴레이할 수 있습니다.
AD FS WAP 서버 는 외부 사용자 요청을 사전 인증하고 페더레이션된 액세스를 위해 AD FS에 안전하게 전달하는 경계 네트워크에 배포된 역방향 프록시 서버입니다.
시나리오 정보
AD FS는 온-프레미스에서 호스트될 수 있지만 애플리케이션이 Azure에서 일부 부분이 구현되는 하이브리드인 경우 클라우드에서 AD FS를 복제하는 것이 더 효율적일 수 있습니다.
이전 다이어그램은 다음과 같은 시나리오를 보여 줍니다.
파트너 조직의 애플리케이션 코드는 Azure 가상 네트워크 내에서 호스트되는 웹 애플리케이션에 액세스합니다.
AD DS(Active Directory Domain Services) 내에 저장된 자격 증명을 가진 등록된 외부 사용자가 Azure 가상 네트워크 내에서 호스트되는 웹 애플리케이션에 액세스합니다.
권한 있는 디바이스를 사용하여 가상 네트워크에 연결된 사용자는 Azure 가상 네트워크 내에서 호스트되는 웹 애플리케이션을 실행합니다.
이 참조 아키텍처는 페 더레이션 서버가 사용자를 인증하는 방법과 시기를 결정하는 수동 페더레이션에 중점을 둡니다. 사용자는 애플리케이션이 시작될 때 로그인 정보를 제공합니다. 이 메커니즘은 웹 브라우저에서 가장 일반적으로 사용되며 브라우저를 사용자가 인증하는 사이트로 리디렉션하는 프로토콜을 포함합니다. 또한 AD FS는 활성 페더레이션을 지원합니다. 여기서 애플리케이션은 추가 사용자 상호 작용 없이 자격 증명을 제공해야 하지만 해당 시나리오는 이 아키텍처의 범위를 벗어버립니다.
다른 고려 사항은 Microsoft Entra ID와 온-프레미스 Active Directory 도메인 통합을 참조하세요.
잠재적인 사용 사례
이 아키텍처의 일반적인 용도는 다음과 같습니다.
작업이 부분적으로 온-프레미스 및 부분적으로 Azure에서 실행되는 하이브리드 애플리케이션
페더레이션된 권한 부여를 사용하여 파트너 조직에 웹 애플리케이션을 노출하는 솔루션
조직 방화벽 외부에서 실행되는 웹 브라우저에서 액세스를 지원하는 시스템
원격 컴퓨터, 노트북 및 다른 모바일 디바이스와 같은 승인된 외부 디바이스에서 연결하여 사용자가 웹 애플리케이션에 액세스할 수 있도록 하는 시스템
Recommendations
대부분의 시나리오에 다음 권장 사항을 적용할 수 있습니다. 이러한 권장 사항을 재정의하라는 특정 요구 사항이 있는 경우가 아니면 따릅니다.
네트워킹 권장 사항
고정 개인 IP 주소가 있는 AD FS 및 WAP 서버를 호스팅하는 각 VM에 대한 네트워크 인터페이스를 구성합니다.
AD FS VM에 공용 IP 주소를 제공하지 마세요. 자세한 내용은 보안 고려 사항 섹션을 참조하세요 .
AD DS VM을 참조하도록 각 AD FS 및 WAP VM에 대한 네트워크 인터페이스에 대한 기본 설정 및 보조 DNS(도메인 이름 서비스) 서버의 IP 주소를 설정합니다. AD DS VM은 DNS를 실행해야 합니다. 이 단계는 각 VM을 도메인에 조인하기 위해 필요합니다.
AD FS 설치
페더레이션 서버 팜 배포 문서에서는 AD FS를 설치하고 구성하는 방법에 대한 자세한 지침을 제공합니다. 팜에서 첫 번째 AD FS 서버를 구성하기 전에 다음 작업을 수행합니다.
서버 인증을 수행하기 위해 공개적으로 신뢰할 수 있는 인증서를 가져옵니다. 주체 이름에는 클라이언트가 페더레이션 서비스에 액세스하는 데 사용하는 이름이 포함되어야 합니다. 이 식별자는 부하 분산 장치에 등록된 DNS 이름(예:
adfs.contoso.com.)일 수 있습니다. 보안상의 이유로 와일드카드 이름을*.contoso.com사용하지 않습니다. 모든 AD FS 서버 VM에 동일한 인증서를 사용합니다. 신뢰할 수 있는 인증 기관에서 인증서를 구입할 수 있지만 조직에서 Active Directory 인증서 서비스를 사용하는 경우 직접 만들 수 있습니다.DRS는 주체 대체 이름을 사용하여 외부 디바이스에서 액세스할 수 있도록 합니다. 이 DNS 이름은 형식
enterpriseregistration.contoso.com을 따라야 합니다.자세한 내용은 AD FS용 Secure Sockets Layer 인증서 가져오기 및 구성을 참조하세요.
도메인 컨트롤러에서 KDS(키 배포 서비스)에 대한 새 루트 키를 생성합니다. 유효 시간을 현재 시간에서 10시간을 뺀 값으로 설정합니다. 이 구성은 도메인 간에 키를 배포하고 동기화할 때 발생할 수 있는 지연을 줄입니다. 이 단계는 AD FS 서비스를 실행하는 데 사용되는 그룹 서비스 계정 만들기를 지원하는 데 필요합니다. 다음 PowerShell 명령은 시간 오프셋을 사용하여 새 KDS 루트 키를 생성하는 방법을 보여 줍니다.
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)각 AD FS 서버 VM을 도메인에 추가합니다.
Note
AD FS를 설치하려면 도메인에 대한 주 도메인 컨트롤러 에뮬레이터 유연한 단일 마스터 작업 역할을 실행하는 도메인 컨트롤러가 AD FS VM에서 실행되고 액세스할 수 있어야 합니다.
AD FS 신뢰
AD FS 설치와 모든 파트너 조직의 페더레이션 서버 간에 페더레이션 트러스트를 설정합니다. 필요한 클레임 필터링 및 매핑을 구성합니다.
각 파트너 조직의 DevOps 직원은 AD FS 서버를 통해 액세스할 수 있는 웹 애플리케이션에 대한 신뢰 당사자 트러스트를 추가해야 합니다.
조직의 DevOps 직원은 AD FS 서버가 파트너 조직에서 제공하는 클레임을 신뢰할 수 있도록 클레임 공급자 트러스트를 구성해야 합니다.
또한 조직의 DevOps 직원은 조직의 웹 애플리케이션에 클레임을 전달하도록 AD FS를 구성해야 합니다.
자세한 내용은 페더레이션 트러스트를 설정합니다.
조직의 웹 애플리케이션을 게시하고 WAP 서버를 통해 사전 인증을 사용하여 외부 파트너에 사용할 수 있도록 합니다. 자세한 내용은 AD FS 사전 인증을 사용하여 애플리케이션 게시를 참조하세요.
AD FS는 토큰 변환 및 확대를 지원합니다. Microsoft Entra ID는 이 기능을 제공하지 않습니다. AD FS를 사용하여 트러스트 관계를 설정할 때 다음 작업을 수행할 수 있습니다.
권한 부여 규칙에 대한 클레임 변환을 구성합니다. 예를 들어 비 Microsoft 파트너 조직에서 사용하는 표현에서 AD DS가 조직에서 권한을 부여할 수 있는 항목으로 그룹 보안을 매핑할 수 있습니다.
클레임을 한 형식에서 다른 형식으로 변환합니다. 예를 들어 애플리케이션이 SAML 1.1 클레임만을 지원하는 경우 SAML 2.0에서 SAML 1.1로 매핑할 수 있습니다.
AD FS 모니터링
AD FS 2012 R2용 Microsoft System Center 관리 팩은 페더레이션 서버에 대한 AD FS 배포에 대한 사전 및 사후 모니터링을 모두 제공합니다. 이 관리 팩은 AD FS 배포의 다음과 같은 측면을 모니터링합니다.
AD FS 서비스가 이벤트 로그에 기록하는 이벤트
AD FS 성능 카운터가 수집하는 성능 데이터
AD FS 시스템 및 웹 애플리케이션(신뢰 당사자)의 전반적인 상태 및 중요한 문제 및 경고
또 다른 옵션은 Microsoft Entra Connect Health를 사용하여 AD FS를 모니터링하는 것입니다. Connect Health 는 온-프레미스 ID 인프라의 모니터링을 제공합니다. 이를 통해 Microsoft 365 및 Microsoft 온라인 서비스에 대한 안정적인 연결을 유지할 수 있습니다. 주요 ID 구성 요소에 대한 모니터링 기능을 제공하여 이러한 안정성을 달성합니다. 또한 이러한 구성 요소에 대한 주요 데이터 요소를 액세스할 수 있도록 합니다.
Considerations
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.
Reliability
안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성 대한디자인 검토 검사 목록을 참조하세요.
서비스의 가용성을 높이기 위해 최소 두 개의 서버가 있는 AD FS 팜을 만듭니다. 팜의 각 AD FS VM에 대해 다른 스토리지 계정을 사용합니다. 이 방법은 단일 스토리지 계정의 오류로 전체 팜에 액세스할 수 없도록 하는 데 도움이 됩니다.
AD FS 및 WAP VM에 대한 별도 Azure 가용성 집합을 만듭니다. 각 집합에 최소 두 개의 VM이 있는지 확인합니다. 각 가용성 집합에는 최소 2개의 업데이트 도메인과 두 개의 장애 도메인이 있어야 합니다.
다음 단계를 수행하여 AD FS VM 및 WAP VM에 대한 부하 분산 장치를 구성합니다.
Azure 부하 분산 장치를 사용하여 WAP VM 및 내부 부하 분산 장치에 대한 외부 액세스를 제공하여 팜의 AD FS 서버에 부하를 분산합니다.
포트 443(HTTPS)에 표시되는 트래픽만 AD FS 또는 WAP 서버에 전달합니다.
부하 분산 장치에 고정 IP 주소를 지정합니다.
에 대해 HTTP를 사용하여 상태 프로브를 만듭니다
/adfs/probe. 자세한 내용은 Azure Load Balancer에 대한 사용자 지정 HTTP/HTTPS 상태 프로브 만들기를 참조하세요.Note
AD FS 서버는 부하 분산 장치의 HTTPS 엔드포인트 프로브가 실패하게 하는 서버 이름 표시 프로토콜을 사용합니다.
AD FS 부하 분산 장치의 도메인에 DNS A 레코드를 추가합니다. 부하 분산 장치의 IP 주소를 지정하고 도메인에 이름을 지정합니다(예:
adfs.contoso.com.). 이 DNS 레코드는 클라이언트와 WAP 서버가 AD FS 서버 팜에 액세스하는 데 사용하는 이름입니다.
SQL Server 또는 Windows 내부 데이터베이스를 사용하여 AD FS 구성 정보를 보관할 수 있습니다. Windows 내부 데이터베이스는 기본 중복성을 제공합니다. 변경 내용은 AD FS 클러스터의 AD FS 데이터베이스 중 하나에 직접 기록되는 반면 다른 서버는 끌어오기 복제를 사용하여 해당 데이터베이스를 최신 상태로 유지합니다. SQL Server를 사용하면 장애 조치(failover) 클러스터링 또는 미러링을 사용하여 전체 데이터베이스 중복성 및 고가용성을 제공할 수 있습니다.
Security
보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안 대한디자인 검토 검사 목록을 참조하세요.
AD FS는 HTTPS를 사용하므로 웹 계층 VM을 포함하는 서브넷에 대한 NSG 규칙이 HTTPS 요청을 허용하는지 확인합니다. 이러한 요청은 온-프레미스 네트워크, 웹 계층, 비즈니스 계층, 데이터 계층, 프라이빗 DMZ, 공용 DMZ 및 AD FS 서버를 포함하는 서브넷을 포함하는 서브넷에서 비롯될 수 있습니다.
AD FS 서버가 인터넷에 직접 노출되지 않도록 합니다. AD FS 서버는 보안 토큰을 부여하는 완전한 권한이 있는 도메인에 가입된 컴퓨터입니다. 서버가 손상되면 악의적인 사용자가 모든 웹 애플리케이션 및 AD FS로 보호되는 모든 페더레이션 서버에 전체 액세스 토큰을 발급할 수 있습니다. 시스템에서 신뢰할 수 있는 파트너 사이트에서 연결하지 않는 게스트의 요청을 처리해야 하는 경우 WAP 서버를 사용하여 이러한 요청을 처리합니다. 자세한 내용은 페더레이션 서버 프록시를 배치할 위치를 참조하세요.
자체 방화벽이 있는 별도의 서브넷에 AD FS 서버 및 WAP 서버를 배치합니다. NSG 규칙을 사용하여 방화벽 규칙을 정의할 수 있습니다. 모든 방화벽은 포트 443(HTTPS)의 트래픽을 허용해야 합니다.
AD FS 및 WAP 서버에 대한 직접 로그인 액세스를 제한합니다. DevOps 직원만 연결할 수 있어야 합니다. WAP 서버를 도메인에 조인하지 마세요.
감사 목적으로 가상 네트워크의 가장자리를 트래버스하는 트래픽에 대한 자세한 정보를 기록하는 네트워크 가상 어플라이언스 집합을 사용하는 것이 좋습니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화 대한디자인 검토 검사 목록을 참조하세요.
Microsoft Entra Domain Services
Microsoft Entra Domain Services를 여러 워크로드가 비용을 절감하기 위해 사용하는 공유 서비스로 사용하는 것이 좋습니다. 자세한 내용은 Domain Services 가격 책정을 참조하세요.
AD FS
Microsoft Entra ID에서 제공하는 버전에 대한 자세한 내용은 Microsoft Entra 가격 책정을 참조하세요. AD FS 기능은 모든 버전에서 사용할 수 있습니다.
운영 효율성
운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 대한디자인 검토 검사 목록을 참조하세요.
DevOps 직원은 다음 작업을 수행할 준비가 되어 있어야 합니다.
AD FS 팜 관리, 페더레이션 서버의 신뢰 정책 관리, 페더레이션 서비스에서 사용하는 인증서 관리 등 페더레이션 서버 관리
WAP 팜 및 인증서 관리를 포함하여 WAP 서버 관리
신뢰 당사자 구성, 인증 방법 및 클레임 매핑을 포함하여 웹 애플리케이션 관리
AD FS 구성 요소 백업
다른 DevOps 고려 사항은 Azure 가상 네트워크에 AD DS 배포를 참조하세요.
성능 효율성
성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성 대한디자인 검토 검사 목록을 참조하세요.
AD FS 배포 계획 문서에서 요약된 다음 고려 사항은 AD FS 팜 크기 조정에 대한 시작 지점을 제공합니다.
사용자가 1,000명 미만인 경우 전용 서버를 만들지 마세요. 대신 클라우드의 각 AD DS 서버에 AD FS를 설치합니다. 가용성을 유지하기 위해 두 개 이상의 AD DS 서버가 있는지 확인합니다. 단일 WAP 서버를 만듭니다.
사용자가 1,000명에서 15,000명 사이인 경우 전용 AD FS 서버 2대와 전용 WAP 서버 2개를 만듭니다.
사용자가 15,000명에서 60,000명 사이인 경우 전용 AD FS 서버 3~5대와 전용 WAP 서버 2개 이상을 만듭니다.
이러한 고려 사항은 Azure에서 이중 쿼드 코어 VM(표준 D4_v2 이상) 크기를 사용하고 있다고 가정합니다.
Windows 내부 데이터베이스를 사용하여 AD FS 구성 데이터를 저장하는 경우 팜에 있는 8개의 AD FS 서버로 제한됩니다. 나중에 더 많은 것이 필요할 수 있다고 생각되면 SQL Server를 사용합니다. 자세한 내용은 AD FS 구성 데이터베이스의 역할을 참조하세요.
Contributors
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
대표 저자:
- 사라 파크스 | 선임 클라우드 솔루션 설계자
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.