원격 사용자를 위해 Active Directory를 공용 인터넷에 공개해야합니까?

Apple과 Windows 7 PC / 랩톱을 혼합하여 사용하는 직원이 전적으로 원격 직원으로 구성된 클라이언트가 있습니다.

현재 사용자는 도메인에 대해 인증을받지 않았지만 몇 가지 이유로 해당 방향으로 이동하려고합니다. 이들은 회사 소유의 컴퓨터이며 계정 비활성화, 그룹 정책 및 일부 데이터 손실 방지 (원격 미디어, USB 비활성화 등)를 일부 제어하려고합니다. 이들은 AD에 액세스하기 위해 VPN 인증이 필요하다는 우려 특히 해고 된 직원과 원격 컴퓨터의 캐시 된 자격 증명이 교차하는 경우 번거로울 수 있습니다.

조직의 대부분의 서비스는 Google 기반 (메일, 파일, 채팅 등)이므로 도메인 서비스 만 DNS 및 Cisco ASA VPN의 인증입니다.

고객이 도메인 컨트롤러를 공개 할 수없는 이유를 알고 싶습니다 . 또한, 무엇 이고 분산 된 원격 인력에 대한 더 허용 도메인 구조는?

편집하다:

Centrify 는 소수의 Mac 클라이언트에서 사용 중입니다.

모든 사람이 IT 내 경험, 타사 정보, 의견 수렴 및 부족 지식을 기반으로 자신의 "교육 된 의견"을 가지고 있기 때문에이 답변을 주로 게시하고 있습니다. 그러나 이것은 Microsoft의 "직접"인용 및 읽기 목록입니다. 직원이 작성한 모든 의견을 제대로 필터링하지 못하기 때문에 따옴표를 사용했지만 authoritativeMicrosoft에서 직접 참조한 후에도 도움이 될 것 입니다.

BTW, DOMAIN CONTROLLER == ACTIVE DIRECTORY라고 말하는 것이 매우 쉽다고 생각합니다. AD FS 프록시 및 기타 수단 (OWA, EAS 등의 양식 기반 인증)은 클라이언트가 DC 자체를 노출시키지 않고 AD를 통해 최소한 인증을 시도 할 수 있도록 AD 자체를 웹에 "노출"하는 방법을 제공합니다. 누군가의 OWA 사이트를 방문하여 로그인을 시도하면 AD 가 백엔드 DC에서 인증 요청을 받으므로 AD는 기술적으로 "노출"되지만 SSL을 통해 보안이 유지되고 Exchange 서버를 통해 프록시됩니다.

인용 # 1

Windows Azure 가상 컴퓨터에 Windows Server Active Directory를 배포하기위한 지침

"Azure is not AD"로 이동하기 전에 Azure VM에 ADDS를 배포 할 수 있습니다.

그러나 관련 비트를 인용하면 :

STS를 인터넷에 직접 노출시키지 마십시오.

최상의 보안 방법으로 STS 인스턴스를 방화벽 뒤에 배치하고 인터넷에 노출되지 않도록 회사 네트워크에 연결하십시오. 이는 STS 역할이 보안 토큰을 발행하기 때문에 중요합니다. 결과적으로 도메인 컨트롤러와 동일한 수준의 보호로 처리해야합니다. STS가 손상된 경우 악의적 인 사용자는 신뢰할 수있는 조직의 당사자 응용 프로그램 및 기타 STS에 대한 신뢰 주장을 포함하는 액세스 토큰을 발급 할 수 있습니다.

어고 ... 도메인 컨트롤러를 인터넷에 직접 노출시키지 마십시오.

인용 # 2

Active Directory-AD LDS의 UnicodePwd 미스터리

인터넷에 도메인 컨트롤러를 노출시키는 것은 프로덕션 환경에서 직접 또는 주변 네트워크를 통해 노출되는지에 관계없이 일반적으로 나쁜 습관입니다. 자연스러운 대안은 주변 네트워크에서 AD LDS (Active Directory Lightweight Directory Services) 역할을 실행하는 Windows Server 2008 서버를 배치하는 것입니다.

인용 # 3-MS가 아니라 앞으로도 계속 유용합니다.

서비스로서의 Active Directory? 클라우드 호스팅 AD 미래를 암시하는 Azure, Intune

결국, Azure 대안 대신 AD 서버의 사무실을 없애는 목표를 달성하는 훌륭한 "짧은"대답은 없습니다. 고객이 Azure에서 Server 2012 및 2008 R2 상자에 Active Directory 도메인 서비스를 호스팅 할 수 있도록 Microsoft가 만족하지는 않지만 직원의 편의를 위해 VPN 연결만큼 유용합니다. DirectAccess는 매우 유망한 기술이지만 불행한 한계로 인해 손이 묶여 있습니다.

인용 # 4

싱글 사인온 및 Windows Azure 가상 컴퓨터를 사용하여 AD DS 또는 AD FS 및 Office 365 배포

도메인 컨트롤러와 AD FS 서버는 인터넷에 직접 노출되어서는 안되며 VPN을 통해서만 연결할 수 있어야합니다

AD (Active Directory)는 이러한 종류의 배포를 위해 설계되지 않았습니다.

제품 설계에 사용 된 위협 모델은 네트워크 경계에서 필터링 된 일부 적대 행위자가 포함 된 "방화벽"배치를 가정합니다. Windows Server가 퍼블릭 네트워크에 노출되도록 확실히 강화할 수 있지만 Active Directory의 올바른 기능을 위해서는 퍼블릭 네트워크 용으로 강화 된 호스트보다 결정적인 보안 상태가 필요합니다. 많은 서비스가 제대로 작동하려면 AD에 대한 도메인 컨트롤러 (DC)에서 노출되어야한다.

의견에 대한 Zoredache의 제안, 특히 인증서 인증을 통해 시스템 전체 서비스로 실행되는 OpenVPN과 같은 것을 언급하는 것이 적합 할 수 있습니다. 다른 사람들이 언급했듯이 DirectAccess는 원하는 크로스 플랫폼 지원이 없다는 것을 제외하고는 정확히 필요한 것입니다.

제쳐두고 : 나는 인증서 기반 전송 모드 IPSEC를 사용하여 AD를 인터넷에 직접 노출시키는 아이디어를 가지고 놀았지만 실제로는 할 시간이 없었습니다. Microsoft는 Windows Server 2008 / Vista 기간을 변경하여이 기능을 구현할 수 있었지만 실제로 실행 한 적은 없었습니다.

다른 사람들이 말한 것. 크리스토퍼 카렐 (Christopher Karel)이 언급 한 무차별 대입 시도에 대해 특히 긴장합니다. 마지막 데프콘에서 발표 된 주제는 다음과 같습니다.

도메인 컨트롤러가 안전하다고 생각하십니까?

저스틴 헨드릭스 보안 엔지니어, 마이크로 소프트

도메인 컨트롤러는 조직의 핵심 보석입니다. 일단 떨어지면 도메인의 모든 것이 떨어집니다. 조직은 도메인 컨트롤러를 보호하기 위해 많은 시간을 투자하지만 이러한 서버를 관리하는 데 사용되는 소프트웨어를 제대로 보호하지 못하는 경우가 많습니다.

이 프레젠테이션에서는 조직에서 배포하고 사용하는 일반적으로 사용되는 관리 소프트웨어를 남용하여 도메인 관리자를 얻는 기존의 방법을 다룹니다.

Justin Hendricks는 Office 365 보안 팀에서 빨간색 팀 구성, 침투 테스트, 보안 연구, 코드 검토 및 도구 개발에 참여하고 있습니다.

다른 많은 예제를 찾을 수 있다고 확신합니다. DC가 얼마나 빨리 발견되는지 등에 대한 설명을 얻기 위해 도메인 컨트롤러 및 해킹에 대한 기사를 찾고 있었지만 지금은 그렇게 할 것이라고 생각합니다.

경영진을 설득하려는 경우 다음과 같이 시작하십시오.

It goes against Microsoft's Best Practices for Active Directory Deployment.

업데이트 : 공격으로부터 도메인 컨트롤러를 보호하는 방법에 대한 이 기술 문서 와 제목 Perimeter Firewall Restrictions이 있는 섹션을 참조하십시오 .

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

그리고 제목 Blocking Internet Access for Domain Controllers은 다음과 같습니다.

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

문제에 관한 Microsoft 문서를 정리할 수 있다고 확신합니다. 그 외에도 다음과 같은 내용으로 이러한 이동의 위험을 설명 할 수 있습니다.

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

캐시 된 자격 증명은 캐시 된 것입니다. 도메인에 연결할 수 없을 때 로컬 컴퓨터에서 작동 하지만 해당 계정이 비활성화되어 있으면 네트워크 리소스 (svn, vpn, smb, fbi, cia 등)에 대해 작동하지 않으므로 걱정할 필요가 없습니다. . 또한 사용자는 로컬 컴퓨터의 프로필 폴더에있는 모든 파일 (이동식 미디어)에 대한 모든 권한을 이미 가지고 있으므로 자격 증명을 비활성화했거나 해당 데이터로 원하는 작업을 수행 할 수 없습니다. 로컬 컴퓨터가 네트워크에 다시 연결되면 로컬 컴퓨터에서도 작동하지 않습니다.

LDAP와 같이 Active Directory 또는 도메인 컨트롤러가 제공하는 서비스를 언급하고 있습니까? 그렇다면 LDAP는 인증 및 디렉토리 조회를 위해 보안이 강화되는 경우가 많지만 Windows 방화벽을 끄거나 (필요한 모든 포트를 공개적으로 공개-이 예제와 동일) 심각한 문제가 발생할 수 있습니다.

AD는 실제로 Mac을 관리 하지 않으므로 별도의 솔루션이 필요합니다 (OS X Server 생각). Mac에 도메인에 가입 할 수는 있지만 네트워크 자격 증명으로 인증하고 도메인 관리자를 Mac의 로컬 관리자로 설정하는 것 이상을 수행 할 수 있습니다. 그룹 정책 없음. MS는 mac 및 * nix 상자에 응용 프로그램을 배포 할 수 있다고 주장하는 최신 버전의 SCCM을 사용하여 이러한 상황을 극복하려고 노력하고 있지만 아직 프로덕션 환경에서는 볼 수 없습니다. 또한 AD 기반 디렉토리를 인증하는 OS X Server에 연결하도록 Mac을 구성 할 수 있다고 생각하지만 잘못되었을 수 있습니다.

즉, OpenVPN을 서비스로 사용하고 직원이 퇴근 할 때가되면 기계 인증서를 사용하지 않도록하는 Evan의 제안과 같은 일부 창의적인 솔루션을 고안 할 수 있습니다.

모든 것이 Google을 기반으로하는 것처럼 들리므로 Google이 LDAP 서버 역할을하고 있습니까? 가능한 한 고객이 그렇게하는 것이 좋습니다. 비즈니스의 특성을 모르지만 git 또는 redmine 서버와 같은 웹 기반 앱의 경우 사내 설정이 Google 계정을 활용하여 OAuth로 인증 할 수있는 경우에도 마찬가지입니다.

마지막으로 이와 같은로드 워리어 설정은 거의 성공 하려면 VPN이 필요 합니다. 컴퓨터를 사무실로 가져 와서 구성하거나 스크립트를 통해 원격으로 구성한 후에는 구성 변경 사항을 수신 할 수있는 방법이 필요합니다.

맥은 VPN 외에도 별도의 관리 접근 방식이 필요하지만 더 이상 실제 맥 서버를 만들지 않지만 너무 나쁘지만 마지막으로 확인했을 때 OS X Server에서 적절한 정책 구현을했습니다 (2 년 전) ).

불행히도 DirectAccess는 요청에 맞게 만들어 졌기 때문에 Win7 + Enterprise Edition에서만 사용할 수 있습니다. 그러나 에디션을 모르고 MacOS가 있다는 것을 알지 못하면 작동하지 않습니다.

/ 편집-일부 타사에서 Unices에 대한 DA 클라이언트가 있다고 주장하는 것 같습니다 : http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

귀하의 요구를 충족시키기 위해 사용할 수있는 MDM 솔루션이 있습니다. 우리는 그 중 하나 (MAAS360)를 비슷한 위치에있는 고객에게 배포하고 있습니다.

이것은 분명히 중대한 보안 위험이 될 것입니다. 또한 원하는대로 작동하지 않을 수도 있습니다. 인터넷상의 임의의 사람들이 AD 환경에 로그인을 시도 할 수 있으면 모든 사용자가 잠기 게 될 가능성이 높습니다. 영원히. 또한 잠금 요구 사항을 제거하면 간단한 암호를 무차별 강제 검사 할 수 있습니다.

더 중요한 것은 AD 서버에 직접 액세스하지 않고도 목표를 구현하는 데 문제가 없어야합니다 (최종 사용자가 도메인 자격 증명으로 랩톱에 로그인). 즉, Windows 시스템은 마지막 X 성공 로그인을 캐시 할 수 있으므로 연결이 끊어졌을 때 동일한 자격 증명이 작동합니다. 즉, 최종 사용자는 AD 서버를 건드릴 필요없이 로그인하여 유용한 작업을 수행 할 수 있습니다. 분명히 다른 주요 회사 리소스에 연결하기 위해 VPN을 사용해야하며 동시에 AD / GPO 설정을 새로 고칠 수 있습니다.

유대감,

귀하의 질문은 매우 유효하며 신중한 검토가 필요합니다.

모든 보안 전문가는 SPI 방화벽, IDS, 호스트 기반 방화벽 등을 포함하여 모든 네트워크 리소스 앞에 보안 계층을 권장합니다. 가능하면 항상 ISA (현재 TMG)와 같은 프록시 경계 게이트웨이 방화벽을 사용해야합니다.

즉, Microsoft Active Directory 2003+에는 공개 된 주요 취약점이 없습니다. LDAP 기술과 해시 알고리즘은 일반적으로 매우 안전합니다. SSL VPN이 OpenSSL을 실행하고 heartbleed에 취약한 경우 SSL VPN보다 안전합니다.

나는 5 가지를 경고 할 것입니다 :

1. 터미널 서버, DNS 서비스, CIFS 및 특히 IIS의 보안 레코드가 심각한 IIS와 같이 네트워크에 연결된 다른 서비스에 대해 걱정하십시오.

2. 유선으로 일반 텍스트 도메인 자격 증명을 전달하지 않도록 보안 인증서와 함께 LDAPS를 사용하십시오. 인증서 서비스를 설치 한 후 자동으로 발생합니다 (PKI에 별도의 시스템 사용).

3. VPN이나 ​​LDAPS를 사용하지 않는 경우 일부 레거시 시스템은 일반 텍스트 암호를 보내므로 방화벽에 패킷 스니퍼를 넣고 트래픽을 감시하고 일반 텍스트 암호를 수정하십시오.

4. MITM 공격으로 인해 기본 인증 메커니즘이 암호를 다운 그레이드하고 약한 NTLM 인증으로 암호를 노출시킬 수 있습니다.

5. 여전히 존재할 수있는 일부 사용자 열거 취약점에주의하십시오.

즉, Active Directory는 보안면에서 훌륭한 실적을 가지고 있습니다. 또한 MS Active Directory는 암호를 저장하지 않으며 해시 만 사용하여 보안 위험의 심각성을 완화 할 수 있습니다.

보다 원활한 보안 인프라의 이점을 누리면 특별한 DNS 서버를 설정하거나 domain.local을 사용할 필요가 없으며 domain.com과 같은 공용 인터넷에서 실제 도메인을 사용할 수 있습니다.

필자의 의견으로는 Active Directory와 같은 보안 기술을 공개적으로 배포하면 상당한 이점이 있으며 Exchange 및 DNS 및 웹 서버와 같은 다른 기술은 이점과 모든 위험을 제공하지 않습니다.

참고 : Active Directory를 배포하면 DNS 서버가 포함됩니다. DNS 서버에서 재귀를 사용하지 않도록 설정하려면 (기본적으로 사용하도록 설정) 그렇지 않으면 서비스 거부 공격에 절대적으로 참여하게됩니다.

건배,

브라이언

Dell (Vintela 구매를 통한 Quest 구매)은 이러한 명시적인 목적으로 F500 기업에 자주 배포되는 크로스 플랫폼 솔루션을 제공합니다 .

고려해야 할 사항 ...

1. 사용자는 항상 연결되어 있습니까? 그렇다면 많은 활성 사용자가 LDAP를 망치고있을 때 융통성이있는 유연한 VM 기반 호스팅 환경을 사용하는 것이 가장 좋습니다.
2. 둘 이상의 물리적 데이터 센터에서 실행 중입니까? 사용자와 시스템 간의 홉 수를 줄이기 위해 AD 서비스 앞에서 지리적로드 밸런싱을 고려하십시오.
3. 또한 # 2에 대한 대답이 예인 경우 여기에 설명 된대로 포리스트를 복제 할 전용 네트워크 리소스를 설정해야합니다 .

또한 사용자가 스로틀 링 된 업 링크를 사용하거나 시끄러운 와이파이 센터 등을 연결하는 경우 방화벽 솔루션이 매우 높은 재전송 속도를 처리 할 수 ​​있는지 확인하십시오.