디렉터리 서비스의 미래는 도메인이 없습니다.

보안, 장치 관리 및 액세스 제어에 대한 기본 접근 방식이 변화하고 있습니다.

30년 동안 이러한 핵심 IT 우선 순위는 온프레미스 도메인 시대에 탁월한 솔루션이었던 Active Directory 및 OpenLDAP와 떼려야 뗄 수 없는 관계였습니다. 그러나 최근 원격 작업으로의 전환은 기존의 경계 보안 및 온프레미스 인프라가 더 이상 클라우드에서 조직의 사용자 ID와 기밀 데이터를 보호하기에 충분하지 않다는 것을 분명히 합니다.

현대적인 작업 환경을 더 잘 관리하려면 디렉터리 서비스의 개별 기능을 재구상하고 이러한 기능을 고정 배선된 성 및 해자 도메인의 오래된 개념에서 분리해야 합니다. 오늘날 가장 중요한 것은 사용자와 장치가 전 세계 어디에 있든 보안을 유지하는 것입니다.

따라서 디렉터리 서비스의 미래는 도메인이 없습니다. 여기 우리가 어떻게 여기까지 왔는지, 도메인리스 기업이 실제로 어떤 모습인지, 조직이 IAM 인프라를 현대화하기 위해 취할 수 있는 단계에 대해 자세히 살펴보겠습니다.

디렉토리 서비스와 도메인 개념의 재해석

우리가 알고 있는 도메인 개념은 본질적으로 1990년대에 설계되었으며 당시의 유선 사무실 환경에서 안전한 사용자 및 컴퓨터 거버넌스를 위한 탁월한 솔루션이었습니다. 그 이후로 대부분의 다른 IT 영역이 완전히 변모했지만 이 모델은 오늘날에도 여전히 대부분의 조직에서 ID 및 액세스 관리에 대한 접근 방식을 뒷받침합니다.

많은 IT 전문가들은 도메인을 당연하게 여기며 다음 논리적 단계는 웹 애플리케이션 SSO(Single Sign-On) 공급자 및 기타 ID 브리지를 추가하여 클라우드 시대에 맞게 확장하고 적용하는 것이라고 가정했습니다. 그러나 보다 실용적인 접근 방식은 도메인이 처음에 해결하도록 설계된 핵심 문제를 되돌아보고 이러한 문제 중 오늘날에도 여전히 관련이 있는 문제를 결정하고 현대적인 혁신을 사용하여 문제를 해결하는 새로운 방법을 모색하는 것일 수 있습니다.

1990년대 중반에서 2000년대 중반까지 사무실 환경은 크게 달랐습니다. 근로자들은 키 카드나 실제 키를 사용하여 벽돌과 박격포 시설에 들어갔습니다. 그들은 책상으로 걸어가 고정된 컴퓨터 앞에 앉았습니다. 이러한 컴퓨터는 이더넷 케이블을 통해 실제 사무실 내부의 일부 내부 데이터 센터 또는 서버 옷장에 연결되었습니다. 해당 중앙 위치 내부에서 도메인 컨트롤러는 로컬 네트워크 내의 IT 리소스에 대한 액세스 권한을 부여했습니다. 그 물리적 네트워크는 차례로 방화벽과 물리적 액세스를 위한 건물 자체에 의해 외부 공격으로부터 보호되었습니다.

당시 이 설정은 기본적으로 안전하고 관리하기 쉬웠으며 사용자가 여러 암호를 관리하거나 뒤에서 일어나는 인증 및 인증 프로세스에 대해 생각할 필요가 없을 정도로 원활한 사용자 경험을 제공했습니다. 모든 워크스테이션에서 Windows 및 Microsoft 프로그램을 실행하는 데스크탑 타워와 함께 환경이 균질했습니다. Active Directory(AD)는 이러한 유형의 환경에 매우 적합하여 사용자에게 최초의 SSO(Single Sign-On) 경험을 제공할 수 있었습니다. 단일 시스템 로그인.

이제 현재로 빠르게 이동하여 해당 건물의 모든 벽을 허물십시오. IT는 클라우드 기술과 널리 사용 가능한 고속 무선 인터넷을 통해 사무실 밖에서의 유연성을 추구하는 추세였습니다. 타워와 튜브 모니터가 있는 고정 컴퓨터 대신 직원들은 이제 거의 모든 곳에서 휴대하고 인터넷에 연결하고 작업을 시작할 수 있는 랩톱 및 기타 장치를 갖게 되었습니다. 그것은 간단히 말해서 도메인이 없는 기업이며 이것이 우리의 현재 현실입니다.

그러나 도메인 외부에서 너무 많은 작업이 발생하는 세상에서 IT 부서는 Active Directory가 한 때 자체적으로 처리했던 문제를 재평가해야 합니다.

도메인 모델의 현대적 단점

Active Directory는 최신 클라우드 리소스 및 비 Windows 운영 체제에 적응하고 통합하는 데 어려움을 겪었으며, Active Directory가 설계된 경계 보안 모델로는 원격 작업자를 보호하기에 충분하지 않습니다.

따라서 문제는 한 때 AD가 제공했던 중앙 집중식 관리 워크플로와 간단하고 안전한 사용자 경험을 Mac 및 Linux 시스템, 웹 앱, 클라우드 서버, 원격 네트워크 를 포함하는 현대적인 환경으로 변환하는 방법입니다. -Prem 인프라도 마찬가지입니다. 사용자는 작업 위치에 관계없이 최소한의 마찰로 IT 리소스에 연결해야 하며 IT 관리자는 사용자 ID와 독점 데이터가 공격으로부터 보호된다는 확신이 있어야 합니다.

문제는 IT가 기존 AD 도메인 환경에서와 같이 최신 사용자 ID를 거의 제어할 수 없다는 것입니다. 애플리케이션은 레거시 한 번 구매, 로컬 설치 아키텍처에서 클라우드 기반 구독 모델로 마이그레이션되었습니다. 일부 앱은 웹 브라우저를 통해 클라우드에서 처리되는 ID 및 구성과 함께 여전히 로컬에 설치됩니다.

자신의 ID를 관리해야 하는 사용자는 수백 개는 아니더라도 수십 개의 암호를 갖게 되며 보안 지침을 무시하고 약한 암호를 공유하거나 재사용하려는 유혹에 직면하게 됩니다.

사용자는 또한 IT의 승인이나 규정 없이 적절하다고 판단되는 새 응용 프로그램에 대한 자신의 계정을 만들려는 유혹을 받을 수 있습니다. 이러한 섀도 IT는 조직에 불필요한 보안 위험을 초래합니다. 그리고 IT에서 관리하는 ID 조차도 자체 사일로에 존재할 수 있으며, 각각의 개별 ID에는 자체 수동 프로비저닝 및 프로비저닝 해제 프로세스가 필요합니다.

과거의 AD ID와 유사한 단일 중앙 ID는 없습니다. 관리자는 연결을 보호하고, 모든 것을 IT의 권한 하에 안전하게 유지하고, 보안 및 규정 준수 기준을 충족하고, 원격 작업을 위해 장치를 준비할 수 있는 새로운 방법이 필요합니다.

시스템과 관련하여 MacBook 및 Linux 시스템은 이제 일반화되었습니다. 노련한 Microsoft 관리자가 한때 Mac 시스템을 직장에 도입하는 것을 반대했지만 이제는 이러한 시스템을 수용하는 것이 표준 관행입니다. 기존 Active Directory 도메인에서 시스템 관리 도구나 MDM과 같은 AD 이외의 다른 포인트 솔루션을 추가하지 않으면 Mac 및 Linux 시스템 관리가 플러시하거나 안전하지 않을 것입니다.

OpenLDAP를 기반으로 구축된 도메인 환경은 훨씬 더 적합하지 않습니다. LDAP 도메인 및 서버는 주로 ID, 비밀번호, 그룹 및 조직 단위를 관리하지만 종종 시스템 관리, 보안 정책 시행 및 클라우드 앱 통합 기능이 부족합니다. IT 리소스는 선택한 인증 프로토콜로 LDAP를 사용하는 것에서 SAML, SCIM, OAuth, OIDC 등과 같은 최신 표준을 활용하는 방향으로 이동했습니다. 또한 레거시 LDAP 환경은 구성 및 유지 관리를 위해 높은 수준의 전문 지식이 필요합니다.

IT 감독에서 위의 공백을 메우는 논리적인 방법은 현대적인 도메인리스 아키텍처를 구현하는 것입니다.

실제로 도메인이 없다는 것은 실제로 무엇을 의미합니까?

경험이 많은 관리자에게는 도메인리스로의 전환이 다소 무섭게 들릴 수 있지만 적절하게 구성된 도메인리스 환경은 오늘날의 IT 환경에서 기존 도메인 설정보다 훨씬 더 안전 할 수 있습니다. 도메인이 없는 환경에서 조직의 보안 태세는 각 개별 사용자, Mac, Windows 또는 Linux 시스템, 그리고 각 구성 요소가 있는 위치에 관계없이 액세스해야 하는 리소스를 포함합니다.

이제 각 IT 리소스에는 자체 경계가 있습니다. 이는 한 번 인증한 후 강화된 더 큰 경계 내에서 본질적으로 보안되지 않은 상태로 작동하는 대신 ID와 액세스 권한이 지속적으로 확인되고 확인됨을 의미합니다. 사용자는 인증을 위해 도메인을 통해 라우팅하는 대신 표준 인터넷 연결을 통해 직접 리소스에 액세스합니다. 그리고 도메인 컨트롤러 대신 클라우드 디렉터리 서비스가 액세스 관리, 사용자 인증 및 보안 적용을 처리합니다.

도메인리스 엔터프라이즈를 실제로 달성할 수 있게 하는 것은 이러한 클라우드 디렉토리 서비스 개념입니다. 그러나 IT의 다른 많은 측면이 효과적으로 클라우드로 마이그레이션되었음에도 불구하고 많은 관리자는 클라우드에서 전체 범위의 디렉터리 서비스를 구현하는 것에 대해 주저하고 있습니다.

대부분의 경우 디렉터리 서비스 자체의 개념이 Active Directory와 떼려야 뗄 수 없는 관계에 있기 때문입니다. 기존 도구는 이 도구가 해결한 개별 문제를 대신합니다. 그리고 도메인의 보안 측면은 더 직관적입니다. 방화벽과 도어록은 친숙하고 통제감을 느끼게 해줍니다. 도메인을 포기하면 공격에 대한 노출이 증가하고 보안에 대한 통제력이 감소하는 것이 당연해 보입니다.

그러나 사실은 방화벽, 네트워크 탐지, 엔드포인트 탐지 및 대응과 같은 조치를 취하더라도 조직은 여전히 ​​침해를 당하고 있습니다. 새로운 공격이 성공할 때마다 뉴스 주기가 시작되면 IT 커뮤니티는 보안에 대한 동일한 접근 방식의 더 우수하고 강력한 버전을 적용하는 방법에 다시 초점을 맞춥니다. 분명히, 예전 방식은 효과가 없습니다. 근본적으로 새로운 클라우드 중심 접근 방식이 필요한 시점입니다.

클라우드 디렉토리 서비스의 핵심 기능

클라우드 디렉토리 서비스 라는 문구는 IAM 범주에 느슨하게 맞는 다양한 솔루션을 설명하는 데 사용되지만 이 문구가 공급업체마다 실제로 의미하는 바를 정확히 파악하기는 어렵습니다.

다른 클라우드 디렉토리 솔루션은 비슷한 기능을 거의 제공하지 않으며 조직의 핵심 ID 공급자로서 AD의 원래 시스템 거버넌스, 인증 및 액세스 제어 기능의 전체 범위를 복제하는 솔루션은 거의 없습니다. 그러나 이것이 바로 클라우드 디렉토리 서비스가 현대적인 도메인리스 아키텍처를 지원하고 보호하기 위해 수행해야 하는 일입니다.

실제로 가치 있는 클라우드 디렉터리 서비스는 실제로 하나의 플랫폼에서 타사 응용 프로그램 및 Windows가 아닌 운영 체제에 대한 액세스를 관리함으로써 AD의 원래 범위를 넘어서야 합니다.

이 구분은 실제 클라우드 디렉터리 서비스를 웹 앱 SSO 플랫폼과 비교할 때 중요합니다. 웹 앱 SSO 플랫폼은 사용자에게 SaaS 애플리케이션에 액세스할 수 있는 하나의 ID를 제공하지만 장치 액세스, 보안 기준을 관리하거나 레거시 또는 온프레미스에 대해 사용자를 인증하지 못할 수 있습니다. 선호하는 authN 프로토콜을 사용하는 리소스. 이러한 의미에서 SAML 기반 SSO는 클라우드 디렉터리 서비스의 한 구성 요소일 뿐입니다. 조건은 상호 교환할 수 없습니다.

클라우드에서 설정된 AD 도메인 모델의 일대일 변환을 생성하는 대신 적절한 클라우드 디렉토리 서비스는 AD의 기능을 구성 요소 부분으로 나누고 각 부분을 재구성합니다. 우리가 당연하게 여기는 해결책에서 개별 문제를 분리할 수 있다면, 우리는 그것을 해결하는 새로운 방법에 도달할 수 있습니다.

도메인리스 엔터프라이즈용으로 구축된 클라우드 디렉터리 서비스에는 다음과 같은 핵심 기능이 필수적입니다.

• 공급업체와 상관없이 온프레미스와 클라우드 모두에서 장치, 애플리케이션, WiFi/VPN, 서버 및 개발 인프라에 액세스할 수 있는 안전한 단일 사용자 ID
• G Suite, Office 365, AWS, AD/Azure 및 HR/급여 시스템을 포함한 다른 서비스의 사용자 ID를 통합하고 통합하는 기능
• 자동화된 사용자 프로비저닝 및 프로비저닝 해제 기능
• Mac, Windows 및 Linux 시스템에 대한 GPO와 같은 정책 제어와 시스템 상태 및 속성에 대한 심층 보고를 통한 원격 시스템 관리
• Mac, Windows 및 Linux 시스템 로그인 시 다중 요소 인증(MFA) 및 거의 모든 기타 IT 리소스에 대한 액세스 및 SSH 키 관리 기능
• 스크립팅, API 또는 PowerShell을 통한 유연하고 자동화된 관리
• 감사 및 규정 준수 요구 사항을 지원하는 자세한 데이터 및 이벤트 로깅

많은 보안 실패의 원인은 위의 구성 요소 중 하나가 전혀 없는 것이 아니라 조직 전체에 균일하게 적용, 시행 및 업데이트할 수 없기 때문입니다. 이를 염두에 두고 중앙 집중식 클라우드 디렉토리 서비스의 가치가 명확해집니다.

도메인리스 전환의 핵심: 장치 신뢰 및 MFA

많은 클라우드 IAM 솔루션이 완전히 브라우저 기반이지만 최신 도메인리스 보안의 핵심인 장치가 빠져 있습니다. 사용자는 게이트웨이가 랩톱, 태블릿 또는 스마트폰이든 관계없이 작업에 대한 물리적 게이트웨이가 여전히 필요합니다. 도메인리스 환경을 보호하는 데 필요한 상당 부분의 지속적인 검증은 장치 신뢰 라고 생각할 수 있는 프레임워크를 사용하여 장치에서 처리해야 합니다.

사용자가 암호 또는 암호가 없는 자격 증명과 MFA의 조합을 사용하여 장치에 한 번 로그인하면 모든 IT 리소스에 안전하게 액세스할 수 있습니다. 모든 거래는 원자 수준에서 보호되고 암호화되므로 표준 인터넷 연결을 통해 안전하게 작업을 수행할 수 있습니다.

사용자 경험은 1990년대 후반/2000년대 초반 중반 AD 도메인에서 데스크톱 컴퓨터에 로그인하는 SSO 경험과 유사하지만, 배후에서 진행되는 일은 훨씬 더 복잡하고 액세스할 수 있는 IT 리소스의 폭은 다음과 같습니다. 훨씬 더.

클라우드 디렉터리 서비스가 장치와 신뢰할 수 있는 관계를 설정하려면 몇 가지 기준을 충족하고 지속적으로 재확인해야 합니다. 이러한 기준은 다음을 확인하는 것을 단순화합니다.

• 올바른 사용자 가 장치에 액세스하고 있으며 해당 사용자는 자신이 말하는 사람입니다.
• 올바른 장치 가 액세스를 요청하고 있습니다.
• 올바른 위치 에서 액세스를 요청하고 있습니다.
• 주어진 리소스 내에서 사용자/기기에 대해 올바른 권한 이 시행되고 있습니다.

여기에서 MFA의 개념이 TOTP 토큰 및 WebAuthn 보안 키와 같은 사용자 대면 측정을 넘어 확장됩니다. 위의 요구 사항은 장치와 클라우드 디렉터리 서비스 간에 확인할 수 있으며 공격자가 함께 복제하는 것이 사실상 불가능한 세 번째, 네 번째, 다섯 번째 및 더 많은 인증 요소를 설정할 수 있습니다.

이러한 반복되는 다중 요소 인증으로 인해 네트워크 침해에 대한 아이디어가 근본적으로 바뀌었습니다. 한 번의 초기 인증 후에 열린 세션 동안 통과할 보안되지 않은 영역이 더 이상 없습니다. 도메인리스 모델에서는 보안 및 액세스 제어가 네트워크 수준에서만이 아니라 각 수준에서 효과적으로 발생하기 때문입니다. 적절한 권한이 있는 올바른 위치에서 액세스하는 올바른 사람과 올바른 시스템만이 데이터와 애플리케이션에 액세스할 수 있습니다.

클라우드 디렉터리 서비스는 GPO와 같은 시스템 거버넌스, 최소 권한 원칙에 따라 구축된 소프트웨어, 전송 및 저장 중인 모든 데이터 암호화의 조합을 통해 장치 신뢰를 설정합니다. 이 접근 방식에 대해 생각하는 또 다른 방법은 제로 트러스트 보안 의 맥락에서입니다.

실제 제로 트러스트 보안

제로 트러스트 보안은 인증을 담당하는 디렉터리 서비스가 사용자, 장치, 응용 프로그램 또는 기타 IT 리소스의 정당성을 결코 당연시하지 않는다는 것을 의미합니다. 이는 직원, 시스템, 애플리케이션 및 네트워크의 4가지 영역을 확보함으로써 달성됩니다.

직원

신뢰할 수 있는 정보 소스 역할을 하는 디렉터리 데이터베이스에 대해 암호(자신이 알고 있는 것)와 MFA 토큰(가지고 있는 것)을 확인하여 자신이 실제로 누구인지 확인하는 시스템이 마련되어 있습니다.

시스템

검증된 사람이 IT 리소스에 액세스하는 데 사용하는 시스템(회사에서 발급한 기계일 가능성이 있음)은 깨끗해야 하고 해당 사람은 해당 기계에 합법적으로 액세스할 수 있어야 합니다. 실제로 이것은 시스템이 알려지고 정책 및 설정이 보안 표준을 시행하고 사용자가 자신이 누구인지에 대한 높은 수준의 확실성을 보장하는 일종의 메커니즘을 의미합니다. 보안 소프트웨어를 확인하고 업데이트합니다. 시스템 원격 측정은 시스템 자체가 손상되지 않았는지 확인하는 데 도움이 됩니다.

애플리케이션

신뢰할 수 있는 시스템에서 적합한 사람만 애플리케이션에 액세스하는 것이 중요합니다. 위의 논리적 확장은 사용자와 컴퓨터가 앱과 앱이 있는 네트워크에 대한 권한이 있는지 확인하고 해당 네트워크의 보안을 확인하는 것입니다. 여기서 VPN 은 애플리케이션 또는 리소스에 대한 보안 터널로서 도메인리스 엔터프라이즈에서 여전히 중요한 역할을 할 수 있습니다.

회로망

사용자가 있는 네트워크가 무엇이든 가능한 한 안전해야 하지만 완전히 안전하지 않더라도 사용자는 VPN을 사용하여 해당 네트워크 내에 보안 영역을 만들 수 있습니다. 또한 MFA 및 VLAN 세분화와 같은 추가 수단을 통해 네트워크를 보호할 수 있습니다.

도메인리스 아키텍처 구현을 위한 첫 번째 단계

클라우드 디렉토리 서비스와 제로 트러스트 보안으로 구현되는 도메인리스 아키텍처에 대한 이러한 아이디어는 순전히 철학적이거나 먼 미래에 대한 열망이 아닙니다. 바로 지금 여기에 있으며 IT 팀은 완전히 또는 즉시 구현을 시작할 수 있습니다. 기존 인프라에 적합한 점진적인 단계적 접근 방식으로

기능하는 AD 도메인에 깊이 투자하는 조직의 경우 클라우드 디렉터리 서비스가 AD 인스턴스를 포함하여 도메인리스 모델의 많은 이점을 제공하고 전체 클라우드 모델의 디딤돌 역할을 할 수 있습니다.

강력한 클라우드 디렉터리 서비스는 핵심 ID 공급자로 독립할 수 있는 기능을 갖기 때문에 100% 도메인리스로 전환할 준비가 되지 않은 조직도 마이그레이션이 합리적일 때 AD에서 원활하게 이동할 수 있는 옵션이 있습니다.

자세히 알아보려면 G2의 클라우드 디렉터리 서비스에 대한 정보를 탐색하십시오.