Quick Overview by 챗GPT 🤖 AD와 엔트라 ID 환경에서 사이버보안을 강화하기 위해 관리자는 잘못된 구성 문제를 해결해야 합니다. 애플리케이션 소유권 관리의 허점, 무제한 이메일 권한 부여, 서버 폐기 후 서비스 계정 미제거, 엔트라 커넥트의 티어 제로 자산 취급 부족 등의 문제가 대표적입니다. 9가지 구성 오류 문제에 대해 적절한 위험 관리 전략을 구현하여 보안 침해와 규정 준수 위반의 위험을 줄이는 방법을 살펴봅니다. |
사이버보안 태세를 강화하기 위한 손쉬운 방법을 찾고 계십니까? 이번 포스팅에서 AD(Active Directory)와 엔트라 ID(Entra ID) 환경에서 흔히 볼 수 있지만 심각한 구성 오류를 확인해 보십시오. 여기서 제안하는 위험 관리 전략을 구현하면 값비싼 보안 침해와 다운타임, 규정 준수 관련 벌금의 위험을 낮출 수 있습니다.
⚠️구성 오류 1 : 권한이 없으면서 특권 엔트라 ID 애플리케이션의 소유자인 사용자
😖문제
엔트라 ID 애플리케이션은 보안 측면에서 상당한 골칫거리가 될 수 있습니다. 실제로 공격자는 자신이 장악한 애플리케이션을 공격을 위한 작업에 사용하는 경우가 많습니다. 예를 들어 러시아 해외 정보국과의 연계를 의심받고 있는 위협 행위자 그룹인 미드나이트 블리자드(Midnight Blizzard)는 마이크로소프트를 상대로 한 잘 알려진 공격을 감행할 때 침해된 오스(OAuth) 애플리케이션의 자격 증명을 사용했습니다.
중요한 구성 오류 하나만으로도 공격자가 엔트라 ID 애플리케이션을 침해해 비 관리 계정을 애플리케이션 소유자로 할당하기가 훨씬 더 쉬워집니다. 애플리케이션 소유자의 권한은 매우 강력해서 싱글사인온(Single-sign On, SSO) 옵션, 프로비저닝 및 사용자 할당, 다른 사용자 추가 또는 제거를 비롯해 애플리케이션에 대한 마이크로소프트 엔트라 구성의 모든 측면을 관리할 수 있습니다.
일반 사용자 계정은 특권 계정만큼 철저히 보호되지는 않는 경우가 많으므로 악의적 행위자에 의해 탈취될 가능성도 그만큼 높습니다. 공격자는 애플리케이션 소유자의 계정을 침해하는 데 성공할 경우 애플리케이션에 대한 방대한 제어 권한을 갖게 됩니다. 이 애플리케이션에 테넌트에 대한 높은 권한이 있다면 기업이 직면하는 위험은 급격히 상승합니다.
💡위험 관리 전략
기업은 애플리케이션 소유권을 갖는 계정을 엄격히 통제해야 합니다(특히 핵심 데이터와 시스템에 대한 높은 액세스 권한을 가진 모든 애플리케이션). 테넌트에 대한 폭넓은 위임 권한을 가진 엔트라 ID 애플리케이션의 소유권은 다중 요소 인증(MFA) 및 기타 엄격한 보안 제어 수단이 적용되는 관리 계정으로 제한되어야 합니다.
⚠️구성 오류 2 : 제한 없는 Mail.ReadWrite 및 Mail.Send 권한을 보유한 엔트라 ID 애플리케이션
😖문제
관리자는 마이크로소프트 그래프(Graph) 애플리케이션 권한을 부여하는 방법으로(앱 역할이라고도 함) 엔트라 ID 애플리케이션에 권한을 부여해서 로그인한 사용자 없이 애플리케이션이 자체 ID로 작업을 수행하도록 할 수 있습니다. 특히 다음과 같은 애플리케이션 권한을 앱에 부여할 수 있습니다.
✔️ ReadWrite : 앱이 이메일을 작성하고 읽고 업데이트할 수 있음
✔️Send : 앱이 이메일을 보낼 수 있음
이런 애플리케이션 권한은 특히 백그라운드 서비스나 데몬 앱에는 상당히 유용할 수 있습니다. 예를 들어 티켓 처리 시스템의 경우 자체 ID를 사용해서 이메일을 읽고 보내는 기능이 필요할 수 있습니다.
그러나 애플리케이션에 Mail.ReadWrite 또는 Mail.Send 권한을 부여할 경우 기본적으로 앱이 기업의 모든 익스체인지 온라인(Exchange Online) 편지함에서 관련 작업을 수행할 수 있게 됩니다. 즉, 공격자는 애플리케이션 제어 권한을 획득하면 모든 편지함에 액세스할 수 있습니다. 공격자가 CEO의 메시지를 읽거나 CFO 편지함에서 메시지를 보냄으로써 기업에 입힐 수 있는 피해를 상상해 보십시오.
💡위험 관리 전략
최소 권한 원칙에 따라 각 엔트라 ID 앱에는 의도한 용도에 필요한 액세스 권한만 부여해야 합니다. 예를 들어 특정 지역 또는 부서에만 사용되도록 만들어진 앱에 기업 내 다른 부서의 편지함에 대한 액세스 권한이 있으면 안 됩니다.
마이크로소프트는 앱의 액세스 권한을 특정 편지함으로 제한할 수 있는 간단한 방법을 제공합니다. 편지함을 편지함이 활성화된 보안 그룹에 넣고 PowerShell cmdlet New-ApplicationAccessPolicy를 사용해서 이 그룹에 대한 애플리케이션 액세스 정책을 구성하면 됩니다.
⚠️구성 오류 3 : 서버를 폐기하면서 서버의 서비스 계정을 제거하지 않음
😖문제
관리자가 서버를 폐기 처분하면서 서버의 서비스 계정을 제거하지 않는 경우가 매우 많습니다. 이는 심각한 보안 위험을 초래합니다. 서비스 계정은 다양한 이유로 공격자들이 탈취하고자 하는 주요 표적입니다. 첫째, 서비스 계정에는 해커들이 쫓는 민감한 데이터 및 기타 리소스에 대한 높은 권한이 부여된 경우가 많습니다. 둘째, 비밀번호가 변경되는 경우가 거의 없어 침해에 매우 취약할 수 있습니다. 셋째, 서비스 계정의 활동은 IT 보안팀의 감시를 손쉽게 피하고 경우에 따라 모니터링에서 명시적으로 제외되기도 하므로 해커가 발각되지 않고 활동할 수 있습니다.
💡위험 관리 전략
IT팀은 서버 폐기가 그냥 전원 플러그만 뽑으면 되는 간단한 작업이 아니라는 것을 기억해야 합니다. 서버의 서비스 계정 제거를 포함한 베스트 프랙티스에 부합하는 포괄적인 프로세스를 마련해서 따라야 합니다.
⚠️구성 오류 4 : 엔트라 커넥트가 티어 제로 자산으로 취급되지 않음
😖문제
점점 더 많은 기업이 가장 미션 크리티컬한 모든 IT 자산, 즉 티어 제로 자산을 정확하게 식별하고 보호하는 것이 필수적임을 인식하고 있습니다. 티어 제로에는 AD에 대한 제어 권한을 행사할 수 있는 모든 자산이 포함됩니다. 대표적인 예는 도메인 관리자, 계정 운영자, 백업 운영자와 같은 특권 그룹과 이 그룹의 구성원입니다.
그러나 티어 제로에는 다른 자산도 포함됩니다. 특히 엔트라 커넥트(Entra Connect)는 하이브리드 IT 환경 관리를 위해 마이크로소프트가 제공하는 강력한 툴입니다. 많은 기업이 엔트라 커넥트를 사용해서 온프레미스, AD 환경, 엔트라 ID 간에 자동으로 ID 데이터를 동기화합니다. 이렇게 해서 사용자는 동일한 자격 증명을 사용해 온프레미스 애플리케이션과 마이크로소프트 365와 같은 클라우드 서비스에 모두 액세스할 수 있습니다.
이 기능을 제공하기 위해 엔트라 커넥트에는 DCSync 권한과 AD 도메인에 있는 모든 계정의 NT 해시에 대한 액세스 권한이 부여됩니다. 따라서 이는 엄격한 위험 관리 전략이 필요한 명백한 핵심 자산입니다. 그러나 엔트라 커넥트는 티어 제로 분류에서 간과되는 경우가 매우 많습니다. 실제로 많은 관리자가 DCSync 권한이 얼마나 강력한지 잘 모릅니다. 이 권한을 가진 계정을 침해한 공격자는 도메인 복제를 악용해 도메인 데이터에 액세스하고 조작할 수 있으며 AD 환경의 무결성과 가용성에도 피해를 입힐 수 있습니다. 또한 엔트라 커넥트가 티어 제로 자산으로 적절히 보호되지 않을 경우 악의적 행위자는 구성을 변조해서 클라우드 시스템으로 횡적 이동하거나 시스템을 사용하지 못하도록 할 수 있습니다.
게다가 동기화에 사용되는 계정은 손쉽게 식별이 가능합니다. "MSOL"로 시작하며, 설명은 항상 문자열 "Account created by Microsoft Azure Active Directory Connect"로 시작하기 때문입니다.
💡위험 관리 전략
티어 제로 자산에 엔트라 커넥트를 포함하고 엄격한 보안 통제를 적용하십시오. 특히 크리덴셜 가드(Credential Guard)와 LAPS(Local Admin Password Solution)를 사용해서 로컬 관리 계정이 티어 제로 계정만 액세스할 수 있는 개별 비밀번호를 받도록 해야 합니다.
⚠️구성 오류 5 : AdminSDHolder를 보호하지 않음
😖문제
기업이 제대로 보호하지 않은 경우가 많은 또 다른 중요한 객체는 AdminSDHolder입니다. 이 AD 객체는 모든 AD 도메인의 시스템(System) 컨테이너에 자동으로 생성되며 특권 계정의 권한 템플릿 역할을 합니다. SDProp 프로세스는 기본적으로 60분마다 AdminSDHolder 객체의 ACL을 모든 보호되는 그룹 및 그 그룹의 구성원들에게 적용하고 템플릿 권한을 복사하여 현재 권한을 덮어씁니다.
이 기능은 표준 권한을 복원해 보안을 강화하기 위한 목적으로 설계되었지만 악용될 수도 있습니다. 공격자가 AdminSDHolder의 ACL을 변경하는 경우 바뀐 권한이 특권 그룹과 사용자에게 적용됩니다. 예를 들어 공격자는 자신이 장악한 계정을 ACL에 적용하고 여기에 광범위한 액세스 권한을 부여할 수 있습니다. 또한 관리자가 이 권한을 제거하더라도 60분마다 자동으로 액세스 권한이 복원되어 공격자에게 AD에 대한 지속적인 관리자 액세스 권한을 제공하게 됩니다.
💡위험 관리 전략
AdminSDHolder ACL을 수정하기 위해서는 관리자 권한이 필요하므로 가장 중요한 위험 관리 전략 중 하나는 특권 계정의 수를 최소화하고 모든 해당 계정을 티어 제로 자산으로 보호하는 것입니다. 또한 AdminSDHolder 객체의 수정 시도에 대해 알림을 받고 즉각 조사 및 대응하는 것도 중요합니다. 더 좋은 방법은 이 중요한 객체에 대한 변경을 차단할 수 있게 해주는 변경 관리 솔루션에 투자하는 것입니다.
⚠️구성 오류 6 : 특권 사용자가 비특권 컴퓨터에 로그인하도록 허용
😖문제
보안 위험을 초래하는 또 다른 중요한 문제는 관리자가 사용자 워크스테이션과 기타 비특권 컴퓨터에 로그인하도록 허용하는 것입니다. 이런 시스템은 PAW와 같은 엄격한 위험 관리 전략으로 보호되지 않으므로 특권 계정의 자격 증명이 악의적 행위자에 의해 침해될 위험이 더 큽니다.
이 구성 문제는 관리 티어 모델이 구현되지 않은 경우 자주 발생하지만 티어 모델이 복잡한 GPO의 조합을 기반으로 하고 오류가 발생하기 쉽고 로컬 관리자가 우회할 위험이 있는 로컬 컴퓨터 구성에 의존하는 경우에도 발생할 수 있습니다.
💡위험 관리 전략
티어 관리 모델을 구현합니다. 이때 인증 정책을 기반으로 하는 것이 가장 좋습니다. 한 티어의 자산이 덜 보호되는(티어 번호가 더 높은) 티어의 리소스에 액세스하지 못하는 핵심 원칙을 준수하는 것이 중요합니다.
⚠️구성 오류 7 : 티어 제로에 속하지 않는 연결된 GPO가 있는 OU에 특권 사용자 계정이 있음
😖문제
티어 관리 모델을 올바르게 구현하려면 기업은 모든 객체가 예외 없이 각자의 티어에 머물도록 해야 합니다. 일반적으로 기업은 모든 특권 사용자 계정과 함께 특권 계정이 포함된 모든 조직 단위(OU)도 티어 제로에 속하는 것으로 인식합니다.
그러나 OU에 연결된 그룹 정책 객체(Group Policy object, GPO)를 간과할 수 있습니다. 티어 제로가 아닌 GPO가 특권 계정이 포함된 OU에 연결되는 경우 보안 위험이 증가합니다. GPO는 연결된 OU의 모든 객체를 제어할 수 있기 때문입니다. 이 경우 GPO를 사용해서 특권 사용자 계정을 장악할 수 있습니다.
또한 관리자는 사용자 GPO를 컴퓨터에 적용하기 위해 그룹 정책의 루프백 기능을 사용하는 경우가 종종 있습니다. 이 방법은 공유 디바이스를 관리할 때 유용하지만, 티어 제로 사용자가 컴퓨터에 로그온하면 해당 컴퓨터에 할당된 사용자 GPO는 마치 GPO가 티어 제로 사용자에게 적용된 것처럼 동작하게 된다는, 놓치기 쉬운 보안 위험을 유발할 수 있습니다.
💡위험 관리 전략
티어 제로 자산을 인벤토리화할 때는 철저히 해야 합니다. 특권 계정이 티어 제로로 분류된 OU에 위치하도록 하고 다른 티어의 OU에서 발견되는 경우 티어 제로 OU로 옮겨야 합니다. 각 티어 제로 OU에 적용된 모든 GPO를 확인하고, 티어 제로가 아닌 GPO를 발견하는 경우 재분류해서 적절히 보호하거나 티어 제로 OU 연결을 해제해야 합니다. 또한 그룹 정책 루프백 기능을 사용할 때는 신중을 기해야 합니다.
⚠️구성 오류 8 : 특권 보안 그룹 중첩
😖문제
IT 전문가는 모든 특권 그룹의 구성원을 쉽고 정확하게 확인할 수 있어야 합니다. 그룹 중첩은 이 명확함을 저해하여 사용자 계정이 부적절한 특권 액세스 권한을 갖도록 할 수 있습니다. 예를 들어 그룹 도메인 사용자를 서버에서 원격 데스크톱 운영자 로컬 그룹의 구성원으로 두는 경우 공격자에게 좋은 표적이 됩니다.
💡위험 관리 전략
모든 특권 그룹은 명확해야 합니다. 즉, 모든 그룹 중첩을 제거하십시오.
⚠️구성 오류 9 : 소유자 또는 문서화된 목적이 없는 보안 그룹
😖문제
IT팀은 일반적으로 특정 보안 그룹에 정확히 무슨 권한이 필요한지, 정확히 어느 사용자가 구성원이 되어야 하는지 알기가 어렵습니다. 기업에는 비즈니스 소유자와 명확하게 문서화된 목적이 없는 보안 그룹이 많습니다. 사용자들이 적정 수준 이상으로 많은 그룹의 구성원인 경우가 많고, 그룹의 수명은 대체로 필요 이상으로 길게 늘어지므로 이는 오버프로비저닝에 따른 보안 위험 증가로 이어질 수 있습니다.
💡위험 관리 전략
모든 보안 그룹에 한 명 이상의 소유자가 있도록 하고 그룹의 목적을 최대한 세부적으로 문서화하십시오. 소유자가 정기적으로 그룹을 검토하고 그룹의 권한과 멤버십을 조정하여 최소 권한 원칙을 적용하도록 하십시오. 소유자가 그룹의 존속 필요성을 증명하지 않는 한 그룹을 삭제하는 그룹 만료 정책을 구현하는 것도 좋습니다.
결론
모든 사이버보안 및 사이버 회복탄력성 전략의 핵심 요소는 환경에서 침해와 다운타임의 위험을 높이는 잘못된 구성을 파악하는 것입니다. 기업에 하이브리드 AD 및 엔트라 ID 환경이 있는 경우 여기서 설명한 구성 실수가 있는지 확인하십시오. 제시된 위험 관리 전략은 보안 태세를 개선하기 위한 빠르고 효과적인 방법입니다.
AD 및 엔트라 ID 구성에 어려움을 겪고 계시거나 재해 복구 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀
Quick Overview by 챗GPT 🤖
AD와 엔트라 ID 환경에서 사이버보안을 강화하기 위해 관리자는 잘못된 구성 문제를 해결해야 합니다. 애플리케이션 소유권 관리의 허점, 무제한 이메일 권한 부여, 서버 폐기 후 서비스 계정 미제거, 엔트라 커넥트의 티어 제로 자산 취급 부족 등의 문제가 대표적입니다. 9가지 구성 오류 문제에 대해 적절한 위험 관리 전략을 구현하여 보안 침해와 규정 준수 위반의 위험을 줄이는 방법을 살펴봅니다.
사이버보안 태세를 강화하기 위한 손쉬운 방법을 찾고 계십니까? 이번 포스팅에서 AD(Active Directory)와 엔트라 ID(Entra ID) 환경에서 흔히 볼 수 있지만 심각한 구성 오류를 확인해 보십시오. 여기서 제안하는 위험 관리 전략을 구현하면 값비싼 보안 침해와 다운타임, 규정 준수 관련 벌금의 위험을 낮출 수 있습니다.
⚠️구성 오류 1 : 권한이 없으면서 특권 엔트라 ID 애플리케이션의 소유자인 사용자
😖문제
엔트라 ID 애플리케이션은 보안 측면에서 상당한 골칫거리가 될 수 있습니다. 실제로 공격자는 자신이 장악한 애플리케이션을 공격을 위한 작업에 사용하는 경우가 많습니다. 예를 들어 러시아 해외 정보국과의 연계를 의심받고 있는 위협 행위자 그룹인 미드나이트 블리자드(Midnight Blizzard)는 마이크로소프트를 상대로 한 잘 알려진 공격을 감행할 때 침해된 오스(OAuth) 애플리케이션의 자격 증명을 사용했습니다.
중요한 구성 오류 하나만으로도 공격자가 엔트라 ID 애플리케이션을 침해해 비 관리 계정을 애플리케이션 소유자로 할당하기가 훨씬 더 쉬워집니다. 애플리케이션 소유자의 권한은 매우 강력해서 싱글사인온(Single-sign On, SSO) 옵션, 프로비저닝 및 사용자 할당, 다른 사용자 추가 또는 제거를 비롯해 애플리케이션에 대한 마이크로소프트 엔트라 구성의 모든 측면을 관리할 수 있습니다.
일반 사용자 계정은 특권 계정만큼 철저히 보호되지는 않는 경우가 많으므로 악의적 행위자에 의해 탈취될 가능성도 그만큼 높습니다. 공격자는 애플리케이션 소유자의 계정을 침해하는 데 성공할 경우 애플리케이션에 대한 방대한 제어 권한을 갖게 됩니다. 이 애플리케이션에 테넌트에 대한 높은 권한이 있다면 기업이 직면하는 위험은 급격히 상승합니다.
💡위험 관리 전략
기업은 애플리케이션 소유권을 갖는 계정을 엄격히 통제해야 합니다(특히 핵심 데이터와 시스템에 대한 높은 액세스 권한을 가진 모든 애플리케이션). 테넌트에 대한 폭넓은 위임 권한을 가진 엔트라 ID 애플리케이션의 소유권은 다중 요소 인증(MFA) 및 기타 엄격한 보안 제어 수단이 적용되는 관리 계정으로 제한되어야 합니다.
⚠️구성 오류 2 : 제한 없는 Mail.ReadWrite 및 Mail.Send 권한을 보유한 엔트라 ID 애플리케이션
😖문제
관리자는 마이크로소프트 그래프(Graph) 애플리케이션 권한을 부여하는 방법으로(앱 역할이라고도 함) 엔트라 ID 애플리케이션에 권한을 부여해서 로그인한 사용자 없이 애플리케이션이 자체 ID로 작업을 수행하도록 할 수 있습니다. 특히 다음과 같은 애플리케이션 권한을 앱에 부여할 수 있습니다.
✔️ ReadWrite : 앱이 이메일을 작성하고 읽고 업데이트할 수 있음
✔️Send : 앱이 이메일을 보낼 수 있음
이런 애플리케이션 권한은 특히 백그라운드 서비스나 데몬 앱에는 상당히 유용할 수 있습니다. 예를 들어 티켓 처리 시스템의 경우 자체 ID를 사용해서 이메일을 읽고 보내는 기능이 필요할 수 있습니다.
그러나 애플리케이션에 Mail.ReadWrite 또는 Mail.Send 권한을 부여할 경우 기본적으로 앱이 기업의 모든 익스체인지 온라인(Exchange Online) 편지함에서 관련 작업을 수행할 수 있게 됩니다. 즉, 공격자는 애플리케이션 제어 권한을 획득하면 모든 편지함에 액세스할 수 있습니다. 공격자가 CEO의 메시지를 읽거나 CFO 편지함에서 메시지를 보냄으로써 기업에 입힐 수 있는 피해를 상상해 보십시오.
💡위험 관리 전략
최소 권한 원칙에 따라 각 엔트라 ID 앱에는 의도한 용도에 필요한 액세스 권한만 부여해야 합니다. 예를 들어 특정 지역 또는 부서에만 사용되도록 만들어진 앱에 기업 내 다른 부서의 편지함에 대한 액세스 권한이 있으면 안 됩니다.
마이크로소프트는 앱의 액세스 권한을 특정 편지함으로 제한할 수 있는 간단한 방법을 제공합니다. 편지함을 편지함이 활성화된 보안 그룹에 넣고 PowerShell cmdlet New-ApplicationAccessPolicy를 사용해서 이 그룹에 대한 애플리케이션 액세스 정책을 구성하면 됩니다.
⚠️구성 오류 3 : 서버를 폐기하면서 서버의 서비스 계정을 제거하지 않음
😖문제
관리자가 서버를 폐기 처분하면서 서버의 서비스 계정을 제거하지 않는 경우가 매우 많습니다. 이는 심각한 보안 위험을 초래합니다. 서비스 계정은 다양한 이유로 공격자들이 탈취하고자 하는 주요 표적입니다. 첫째, 서비스 계정에는 해커들이 쫓는 민감한 데이터 및 기타 리소스에 대한 높은 권한이 부여된 경우가 많습니다. 둘째, 비밀번호가 변경되는 경우가 거의 없어 침해에 매우 취약할 수 있습니다. 셋째, 서비스 계정의 활동은 IT 보안팀의 감시를 손쉽게 피하고 경우에 따라 모니터링에서 명시적으로 제외되기도 하므로 해커가 발각되지 않고 활동할 수 있습니다.
💡위험 관리 전략
IT팀은 서버 폐기가 그냥 전원 플러그만 뽑으면 되는 간단한 작업이 아니라는 것을 기억해야 합니다. 서버의 서비스 계정 제거를 포함한 베스트 프랙티스에 부합하는 포괄적인 프로세스를 마련해서 따라야 합니다.
⚠️구성 오류 4 : 엔트라 커넥트가 티어 제로 자산으로 취급되지 않음
😖문제
점점 더 많은 기업이 가장 미션 크리티컬한 모든 IT 자산, 즉 티어 제로 자산을 정확하게 식별하고 보호하는 것이 필수적임을 인식하고 있습니다. 티어 제로에는 AD에 대한 제어 권한을 행사할 수 있는 모든 자산이 포함됩니다. 대표적인 예는 도메인 관리자, 계정 운영자, 백업 운영자와 같은 특권 그룹과 이 그룹의 구성원입니다.
그러나 티어 제로에는 다른 자산도 포함됩니다. 특히 엔트라 커넥트(Entra Connect)는 하이브리드 IT 환경 관리를 위해 마이크로소프트가 제공하는 강력한 툴입니다. 많은 기업이 엔트라 커넥트를 사용해서 온프레미스, AD 환경, 엔트라 ID 간에 자동으로 ID 데이터를 동기화합니다. 이렇게 해서 사용자는 동일한 자격 증명을 사용해 온프레미스 애플리케이션과 마이크로소프트 365와 같은 클라우드 서비스에 모두 액세스할 수 있습니다.
이 기능을 제공하기 위해 엔트라 커넥트에는 DCSync 권한과 AD 도메인에 있는 모든 계정의 NT 해시에 대한 액세스 권한이 부여됩니다. 따라서 이는 엄격한 위험 관리 전략이 필요한 명백한 핵심 자산입니다. 그러나 엔트라 커넥트는 티어 제로 분류에서 간과되는 경우가 매우 많습니다. 실제로 많은 관리자가 DCSync 권한이 얼마나 강력한지 잘 모릅니다. 이 권한을 가진 계정을 침해한 공격자는 도메인 복제를 악용해 도메인 데이터에 액세스하고 조작할 수 있으며 AD 환경의 무결성과 가용성에도 피해를 입힐 수 있습니다. 또한 엔트라 커넥트가 티어 제로 자산으로 적절히 보호되지 않을 경우 악의적 행위자는 구성을 변조해서 클라우드 시스템으로 횡적 이동하거나 시스템을 사용하지 못하도록 할 수 있습니다.
게다가 동기화에 사용되는 계정은 손쉽게 식별이 가능합니다. "MSOL"로 시작하며, 설명은 항상 문자열 "Account created by Microsoft Azure Active Directory Connect"로 시작하기 때문입니다.
💡위험 관리 전략
티어 제로 자산에 엔트라 커넥트를 포함하고 엄격한 보안 통제를 적용하십시오. 특히 크리덴셜 가드(Credential Guard)와 LAPS(Local Admin Password Solution)를 사용해서 로컬 관리 계정이 티어 제로 계정만 액세스할 수 있는 개별 비밀번호를 받도록 해야 합니다.
⚠️구성 오류 5 : AdminSDHolder를 보호하지 않음
😖문제
기업이 제대로 보호하지 않은 경우가 많은 또 다른 중요한 객체는 AdminSDHolder입니다. 이 AD 객체는 모든 AD 도메인의 시스템(System) 컨테이너에 자동으로 생성되며 특권 계정의 권한 템플릿 역할을 합니다. SDProp 프로세스는 기본적으로 60분마다 AdminSDHolder 객체의 ACL을 모든 보호되는 그룹 및 그 그룹의 구성원들에게 적용하고 템플릿 권한을 복사하여 현재 권한을 덮어씁니다.
이 기능은 표준 권한을 복원해 보안을 강화하기 위한 목적으로 설계되었지만 악용될 수도 있습니다. 공격자가 AdminSDHolder의 ACL을 변경하는 경우 바뀐 권한이 특권 그룹과 사용자에게 적용됩니다. 예를 들어 공격자는 자신이 장악한 계정을 ACL에 적용하고 여기에 광범위한 액세스 권한을 부여할 수 있습니다. 또한 관리자가 이 권한을 제거하더라도 60분마다 자동으로 액세스 권한이 복원되어 공격자에게 AD에 대한 지속적인 관리자 액세스 권한을 제공하게 됩니다.
💡위험 관리 전략
AdminSDHolder ACL을 수정하기 위해서는 관리자 권한이 필요하므로 가장 중요한 위험 관리 전략 중 하나는 특권 계정의 수를 최소화하고 모든 해당 계정을 티어 제로 자산으로 보호하는 것입니다. 또한 AdminSDHolder 객체의 수정 시도에 대해 알림을 받고 즉각 조사 및 대응하는 것도 중요합니다. 더 좋은 방법은 이 중요한 객체에 대한 변경을 차단할 수 있게 해주는 변경 관리 솔루션에 투자하는 것입니다.
⚠️구성 오류 6 : 특권 사용자가 비특권 컴퓨터에 로그인하도록 허용
😖문제
보안 위험을 초래하는 또 다른 중요한 문제는 관리자가 사용자 워크스테이션과 기타 비특권 컴퓨터에 로그인하도록 허용하는 것입니다. 이런 시스템은 PAW와 같은 엄격한 위험 관리 전략으로 보호되지 않으므로 특권 계정의 자격 증명이 악의적 행위자에 의해 침해될 위험이 더 큽니다.
이 구성 문제는 관리 티어 모델이 구현되지 않은 경우 자주 발생하지만 티어 모델이 복잡한 GPO의 조합을 기반으로 하고 오류가 발생하기 쉽고 로컬 관리자가 우회할 위험이 있는 로컬 컴퓨터 구성에 의존하는 경우에도 발생할 수 있습니다.
💡위험 관리 전략
티어 관리 모델을 구현합니다. 이때 인증 정책을 기반으로 하는 것이 가장 좋습니다. 한 티어의 자산이 덜 보호되는(티어 번호가 더 높은) 티어의 리소스에 액세스하지 못하는 핵심 원칙을 준수하는 것이 중요합니다.
⚠️구성 오류 7 : 티어 제로에 속하지 않는 연결된 GPO가 있는 OU에 특권 사용자 계정이 있음
😖문제
티어 관리 모델을 올바르게 구현하려면 기업은 모든 객체가 예외 없이 각자의 티어에 머물도록 해야 합니다. 일반적으로 기업은 모든 특권 사용자 계정과 함께 특권 계정이 포함된 모든 조직 단위(OU)도 티어 제로에 속하는 것으로 인식합니다.
그러나 OU에 연결된 그룹 정책 객체(Group Policy object, GPO)를 간과할 수 있습니다. 티어 제로가 아닌 GPO가 특권 계정이 포함된 OU에 연결되는 경우 보안 위험이 증가합니다. GPO는 연결된 OU의 모든 객체를 제어할 수 있기 때문입니다. 이 경우 GPO를 사용해서 특권 사용자 계정을 장악할 수 있습니다.
또한 관리자는 사용자 GPO를 컴퓨터에 적용하기 위해 그룹 정책의 루프백 기능을 사용하는 경우가 종종 있습니다. 이 방법은 공유 디바이스를 관리할 때 유용하지만, 티어 제로 사용자가 컴퓨터에 로그온하면 해당 컴퓨터에 할당된 사용자 GPO는 마치 GPO가 티어 제로 사용자에게 적용된 것처럼 동작하게 된다는, 놓치기 쉬운 보안 위험을 유발할 수 있습니다.
💡위험 관리 전략
티어 제로 자산을 인벤토리화할 때는 철저히 해야 합니다. 특권 계정이 티어 제로로 분류된 OU에 위치하도록 하고 다른 티어의 OU에서 발견되는 경우 티어 제로 OU로 옮겨야 합니다. 각 티어 제로 OU에 적용된 모든 GPO를 확인하고, 티어 제로가 아닌 GPO를 발견하는 경우 재분류해서 적절히 보호하거나 티어 제로 OU 연결을 해제해야 합니다. 또한 그룹 정책 루프백 기능을 사용할 때는 신중을 기해야 합니다.
⚠️구성 오류 8 : 특권 보안 그룹 중첩
😖문제
IT 전문가는 모든 특권 그룹의 구성원을 쉽고 정확하게 확인할 수 있어야 합니다. 그룹 중첩은 이 명확함을 저해하여 사용자 계정이 부적절한 특권 액세스 권한을 갖도록 할 수 있습니다. 예를 들어 그룹 도메인 사용자를 서버에서 원격 데스크톱 운영자 로컬 그룹의 구성원으로 두는 경우 공격자에게 좋은 표적이 됩니다.
💡위험 관리 전략
모든 특권 그룹은 명확해야 합니다. 즉, 모든 그룹 중첩을 제거하십시오.
⚠️구성 오류 9 : 소유자 또는 문서화된 목적이 없는 보안 그룹
😖문제
IT팀은 일반적으로 특정 보안 그룹에 정확히 무슨 권한이 필요한지, 정확히 어느 사용자가 구성원이 되어야 하는지 알기가 어렵습니다. 기업에는 비즈니스 소유자와 명확하게 문서화된 목적이 없는 보안 그룹이 많습니다. 사용자들이 적정 수준 이상으로 많은 그룹의 구성원인 경우가 많고, 그룹의 수명은 대체로 필요 이상으로 길게 늘어지므로 이는 오버프로비저닝에 따른 보안 위험 증가로 이어질 수 있습니다.
💡위험 관리 전략
모든 보안 그룹에 한 명 이상의 소유자가 있도록 하고 그룹의 목적을 최대한 세부적으로 문서화하십시오. 소유자가 정기적으로 그룹을 검토하고 그룹의 권한과 멤버십을 조정하여 최소 권한 원칙을 적용하도록 하십시오. 소유자가 그룹의 존속 필요성을 증명하지 않는 한 그룹을 삭제하는 그룹 만료 정책을 구현하는 것도 좋습니다.
결론
모든 사이버보안 및 사이버 회복탄력성 전략의 핵심 요소는 환경에서 침해와 다운타임의 위험을 높이는 잘못된 구성을 파악하는 것입니다. 기업에 하이브리드 AD 및 엔트라 ID 환경이 있는 경우 여기서 설명한 구성 실수가 있는지 확인하십시오. 제시된 위험 관리 전략은 보안 태세를 개선하기 위한 빠르고 효과적인 방법입니다.
AD 및 엔트라 ID 구성에 어려움을 겪고 계시거나 재해 복구 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀