손상에 대한 방안

  • 아티클

적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

법률 번호 7: 가장 안전한 네트워크는 잘 관리되는 네트워크입니다. - 10 변경할 수 없는 보안 관리

치명적인 손상 이벤트가 발생한 조직에서 일반적으로 평가에 따르면 조직은 IT 인프라의 실제 상태에 대한 가시성이 제한되어 있으며 이는 "문서화된 대로" 상태와 크게 다를 수 있습니다. 이러한 차이로 인해 환경이 손상될 수 있는 취약성이 발생하며, 공격자가 환경을 효과적으로 "소유"하는 지점까지 손상이 진행될 때까지 검색 위험이 거의 없는 경우가 많습니다.

이러한 조직의 AD DS 구성, 공개 키 인프라(PPI), 서버, 워크스테이션, 애플리케이션, ACL(액세스 제어 목록) 및 기타 기술에 대한 자세한 평가는 수정된 경우 초기 손상을 방지할 수 있는 잘못된 구성 및 취약성을 보여줍니다.

IT 설명서, 프로세스 및 절차를 분석하면 공격자가 Active Directory 포리스트를 완전히 손상시키는 데 사용된 권한을 얻기 위해 활용한 관리 관행의 격차로 인해 발생하는 취약성을 식별합니다. 완전히 손상된 포리스트는 공격자가 개별 시스템, 애플리케이션 또는 사용자 계정뿐만 아니라 액세스를 에스컬레이션하여 포리스트의 모든 측면을 수정하거나 파괴할 수 있는 권한 수준을 얻는 포리스트입니다. Active Directory 설치가 그 정도까지 손상되면 공격자는 환경 전체에서 기본 존재 여부를 파악할 수 있도록 변경하거나 더 나쁜 경우 디렉터리와 관리하는 시스템 및 계정을 삭제할 수 있습니다.

다음 설명에서 일반적으로 악용되는 여러 취약성은 Active Directory에 대한 공격이 아니지만 공격자가 권한 상승(권한 상승이라고도 함) 공격을 실행하고 결국 AD DS를 대상으로 지정하고 손상시키는 데 사용할 수 있는 환경에서 발판을 마련할 수 있습니다.

이 문서의 이 섹션에서는 공격자가 인프라에 액세스하고 결국 권한 상승 공격을 시작하는 데 일반적으로 사용하는 메커니즘을 설명하는 데 중점을 둡니다. 또한 다음 섹션을 참조하세요.

참고 항목

이 문서에서는 AD DS의 일부인 Active Directory 및 Windows 시스템에 중점을 두지만기본 공격자는 Active Directory 및 Windows에만만 집중하는 경우가 거의 없습니다. 운영 체제, 디렉터리, 애플리케이션 및 데이터 리포지토리가 혼합된 환경에서는 Windows가 아닌 시스템도 손상되었음을 확인하는 것이 일반적입니다. 특히 시스템에서 Windows 및 UNIX 또는 Linux 클라이언트에서 액세스하는 파일 서버, 여러 운영 체제에 인증 서비스를 제공하는 디렉터리 또는 서로 다른 디렉터리 간에 데이터를 동기화하는 메타디렉터와 같은 Windows 및 비 Windows 환경 간에 "브리지"를 제공하는 경우 특히 그렇습니다.

AD DS는 Windows 시스템뿐만 아니라 다른 클라이언트에도 제공하는 중앙 집중식 액세스 및 구성 관리 기능으로 인해 대상으로 지정됩니다. 인증 및 구성 관리 서비스를 제공하는 다른 모든 디렉터리 또는 애플리케이션은 결정된 공격자의 대상이 될 수 있습니다. 이 문서는 Active Directory 설치의 손상 가능성을 줄일 수 있는 보호에 초점을 맞추고 있지만, 비 Windows 컴퓨터, 디렉터리, 애플리케이션 또는 데이터 리포지토리를 포함하는 모든 조직도 해당 시스템에 대한 공격에 대비해야 합니다.

초기 위반 대상

조직을 손상시킬 수 있는 IT 인프라를 의도적으로 빌드하는 사람은 아무도 없습니다. Active Directory 포리스트가 처음 생성되면 일반적으로 자연 그대로의 현재 포리스트입니다. 몇 년이 지나고 새로운 운영 체제 및 애플리케이션이 확보되면 포리스트에 추가됩니다. Active Directory에서 제공하는 관리 효율성 혜택이 인식되고 점점 더 많은 콘텐츠가 디렉터리에 추가됨에 따라 더 많은 사용자가 컴퓨터 또는 애플리케이션을 AD DS와 통합하고 기본 최신 버전의 Windows 운영 체제에서 제공하는 새로운 기능을 지원하도록 업그레이드됩니다. 그러나 시간이 지남에 따라 새로운 인프라가 추가되는 동안에도 인프라의 다른 부분이 기본 달성되지 않을 수 있으며, 시스템과 애플리케이션이 제대로 작동하고 있으므로 관심을 받지 못하고 있으며, 조직은 레거시 인프라를 제거하지 않았다는 사실을 잊기 시작합니다. 손상된 인프라, 더 오래되고 더 크고 복잡한 환경을 평가할 때 볼 수 있는 내용에 따라 일반적으로 악용되는 취약성의 인스턴스가 많을 가능성이 높습니다.

공격자의 동기에 관계없이 대부분의 정보 보안 위반은 한 번에 하나 또는 두 개의 시스템이 손상되는 것으로 시작합니다. 이러한 초기 이벤트 또는 네트워크 진입점은 종종 수정되었을 수 있지만 그렇지 않은 취약성을 활용합니다. 2012년 데이터 위반 조사 보고서(DBIR)는 Verizon RISK 팀이 다수의 국가 안보 기관 및 기타 회사와 협력하여 작성한 연례 연구로, 공격의 96%가 "매우 어렵지 않다"며 "위반의 97%는 단순 또는 중간 통제를 통해 피할 수 있었다"고 명시하고 있습니다. 이러한 발견은 다음에 일반적으로 악용되는 취약성의 직접적인 결과일 수 있습니다.

바이러스 백신 및 맬웨어 방지 배포의 간격

법 번호 8: 오래된 맬웨어 스캐너는 스캐너보다 약간 더 낫습니다. - 변경할 수 없는 10가지 보안법(버전 2.0)

조직의 바이러스 백신 및 맬웨어 방지 배포를 분석하면 대부분의 워크스테이션이 활성화되고 최신 상태인 바이러스 백신 및 맬웨어 방지 소프트웨어로 구성된 환경이 종종 표시됩니다. 예외는 일반적으로 바이러스 백신 및 맬웨어 방지 소프트웨어를 배포, 구성 및 업데이트하기 어려울 수 있는 회사 환경 또는 직원 디바이스에 자주 연결하는 워크스테이션입니다.

그러나 서버 모집단은 많은 손상된 환경에서 덜 일관되게 보호되는 경향이 있습니다. 2012년 데이터 위반 조사에 보고된 바와 같이, 모든 데이터 손상의 94%가 서버를 포함했으며, 이는 전년 대비 18% 증가했으며 공격의 69%는 맬웨어를 통합했습니다. 서버 모집단에서 바이러스 백신 및 맬웨어 방지 설치가 일관되지 않게 구성되거나, 오래되었거나, 잘못 구성되었거나, 사용하지 않도록 설정되는 경우는 드물지 않습니다. 경우에 따라 관리자가 바이러스 백신 및 맬웨어 방지 소프트웨어를 사용하지 않도록 설정하지만, 다른 경우에는 공격자가 다른 취약성을 통해 서버를 손상한 후 소프트웨어를 사용하지 않도록 설정합니다. 바이러스 백신 및 맬웨어 방지 소프트웨어를 사용하지 않도록 설정하면 공격자는 서버에 맬웨어를 심고 서버 모집단에 걸쳐 타협을 전파하는 데 집중합니다.

시스템이 현재 포괄적인 맬웨어 보호로 보호되도록 할 뿐만 아니라 바이러스 백신 및 맬웨어 방지 소프트웨어의 사용 안 함 또는 제거를 위해 시스템을 모니터링하고 수동으로 사용하지 않도록 설정할 때 자동으로 보호를 다시 시작하는 것이 중요합니다. 바이러스 백신 및 맬웨어 방지 소프트웨어는 모든 감염의 예방 및 탐지를 보장할 수 없지만 올바르게 구성되고 배포된 바이러스 백신 및 맬웨어 방지 구현은 감염 가능성을 줄일 수 있습니다.

불완전한 패치

법률 번호 3: 보안 수정 사항을 따라가지 않으면 네트워크는 오랫동안 사용자의 네트워크가 되지 않습니다. - 10 변경할 수 없는 보안 관리

Microsoft는 매월 두 번째 화요일에 보안 공지를 릴리스하지만, 드문 경우지만, 취약성이 고객 시스템에 긴급한 위험을 초래하는 것으로 판단될 때 월별 보안 업데이트("대역 외" 업데이트라고도 함) 간에 보안 업데이트가 릴리스됩니다. 중소기업이 Windows 업데이트 사용하여 시스템 및 애플리케이션 패치를 관리하도록 Windows 컴퓨터를 구성하든, 대규모 조직에서 Microsoft Endpoint Configuration Manager와 같은 관리 소프트웨어를 사용하여 상세하고 계층적인 계획에 따라 패치를 배포하든, 많은 고객이 비교적 시기 적절하게 Windows 인프라를 패치합니다.

그러나 Windows 컴퓨터와 Microsoft 애플리케이션만 포함하는 인프라는 거의 없으며 손상된 환경에서는 조직의 패치 관리 전략에 간격이 있음을 확인하는 것이 일반적입니다. 이러한 환경의 Windows 시스템은 일관되지 않게 패치됩니다. 비 Windows 운영 체제는 산발적으로 패치됩니다(있는 경우). 상용 COTS(상용) 애플리케이션에는 패치가 존재하지만 적용되지 않은 취약성이 포함되어 있습니다. 네트워킹 디바이스는 종종 공장 기본 자격 증명으로 구성되며 설치 후 몇 년 후에는 펌웨어 업데이트가 없습니다. 더 이상 공급업체에서 지원하지 않는 애플리케이션 및 운영 체제는 취약성에 대해 더 이상 패치할 수 없음에도 불구하고 계속 실행되는 경우가 많습니다. 이러한 패치되지 않은 각 시스템은 공격자에게 또 다른 잠재적 진입점을 나타냅니다.

IT 소비자화로 인해 직원 소유 디바이스가 회사 소유 데이터에 액세스하는 데 사용되고 있으며, 조직은 직원의 개인 디바이스의 패치 및 구성을 거의 또는 전혀 제어할 수 없다는 추가 문제가 발생했습니다. 엔터프라이즈급 하드웨어는 일반적으로 개별 사용자 지정 및 디바이스 선택에서 선택의 여지가 적은 비용으로 엔터프라이즈 지원 구성 옵션 및 관리 기능을 제공합니다. 직원 중심 하드웨어는 광범위한 제조업체, 공급업체, 하드웨어 보안 기능, 소프트웨어 보안 기능, 관리 기능 및 구성 옵션을 제공하며 많은 엔터프라이즈 기능이 모두 없을 수 있습니다.

패치 및 취약성 관리 소프트웨어

Windows 시스템 및 Microsoft 애플리케이션에 대한 효과적인 패치 관리 시스템이 있는 경우 패치되지 않은 취약성이 생성되는 공격 표면의 일부가 해결되었습니다. 그러나 비 Windows 시스템, 비 Microsoft 애플리케이션, 네트워크 인프라 및 직원 디바이스도 패치 및 기타 수정 사항을 최신 상태로 유지하지 않는 한 인프라는 다시 취약합니다기본. 경우에 따라 애플리케이션의 공급업체가 자동 업데이트 기능을 제공할 수 있습니다. 다른 경우에는 패치 및 기타 수정 사항을 정기적으로 검색하고 적용하는 방법을 고안해야 할 수도 있습니다.

오래된 애플리케이션 및 운영 체제

"6개월 된 운영 체제가 6개월 된 공격으로부터 당신을 보호할 것으로 기대할 수 없습니다." - 10년 동안 엔터프라이즈 설치를 보호해온 정보 보안 전문가

"최신 상태, 최신 상태 유지"는 마케팅 문구처럼 들릴 수 있지만 오래된 운영 체제 및 애플리케이션은 많은 조직의 IT 인프라에서 위험을 초래합니다. 2003년에 릴리스된 운영 체제는 여전히 공급업체에서 지원되고 취약성을 해결하기 위한 업데이트를 제공할 수 있지만 해당 운영 체제에는 최신 버전의 운영 체제에 추가된 보안 기능이 포함되지 않을 수 있습니다. 오래된 시스템은 해당 컴퓨터의 더 작은 기능을 지원하기 위해 특정 AD DS 보안 구성을 약화해야 할 수도 있습니다.

더 이상 애플리케이션을 지원하지 않는 공급업체가 레거시 인증 프로토콜을 사용하도록 작성된 애플리케이션은 일반적으로 더 강력한 인증 메커니즘을 지원하도록 재정비할 수 없습니다. 그러나 조직의 Active Directory do기본 이러한 애플리케이션을 지원하기 위해 LAN 관리자 해시 또는 역방향으로 암호화된 암호를 저장하도록 구성될 수 있습니다. 최신 운영 체제가 도입되기 전에 작성된 애플리케이션은 현재 운영 체제에서 잘 작동하지 않거나 전혀 작동하지 않을 수 있으므로 조직에서 기본 이전 및 이전 시스템, 경우에 따라 완전히 지원되지 않는 하드웨어 및 소프트웨어를 획득해야 합니다.

조직에서 do기본 컨트롤러를 Windows Server 2012, Windows Server 2008 R2 또는 Windows Server 2008로 업데이트한 경우에도 일반적으로 Windows Server 2003, Windows 2000 Server 또는 Windows NT Server 4.0(완전히 지원되지 않음)을 실행하는 멤버 서버 모집단의 상당 부분을 찾는 것이 일반적입니다. 조직이 노후화된 시스템을 기본 길수록 기능 집합 간의 차이가 커지고 프로덕션 시스템이 지원되지 않을 가능성이 높아집니다. 또한 Active Directory 포리스트가 기본 길수록 업그레이드 계획에서 레거시 시스템과 애플리케이션이 누락되는 것을 더 많이 관찰할 수 있습니다. 이는 Active Directory가 레거시 프로토콜 및 인증 메커니즘을 지원하도록 구성되었으므로 단일 애플리케이션을 실행하는 단일 컴퓨터에서 do기본 또는 포리스트 차원의 취약성을 도입할 수 있음을 의미할 수 있습니다.

레거시 시스템 및 애플리케이션을 제거하려면 먼저 해당 시스템 및 애플리케이션을 식별하고 카탈로그화한 다음, 애플리케이션 또는 호스트를 업그레이드하거나 바꿀지 결정하는 데 집중해야 합니다. 지원 또는 업그레이드 경로가 없는 고도로 특수화된 애플리케이션에 대한 대체 항목을 찾기는 어려울 수 있지만 , "창의적 소멸"이라는 개념을 활용하여 레거시 애플리케이션을 필요한 기능을 제공하는 새 애플리케이션으로 대체할 수 있습니다. 손상 계획은 이 문서의 뒷부분에 있는 "손상 계획"에 대해 자세히 설명합니다.

잘못된 구성

4법: 처음에는 보안이 유지되지 않은 컴퓨터에 보안 수정 사항을 설치하는 것은 별로 좋지 않습니다. - 10 변경할 수 없는 보안 관리

시스템이 일반적으로 최신 상태로 유지되고 패치된 환경에서도 일반적으로 운영 체제, 컴퓨터에서 실행되는 애플리케이션 및 Active Directory의 간격 또는 잘못된 구성을 식별합니다. 일부 잘못된 구성으로 로컬 컴퓨터만 손상될 수 있지만 컴퓨터가 "소유"된 후 공격자는 일반적으로 다른 시스템 간에 손상을 추가로 전파하고 결국 Active Directory로 전파하는 데 집중합니다. 다음은 위험을 초래하는 구성을 식별하는 몇 가지 공통 영역입니다.

Active Directory에서

공격자가 가장 일반적으로 대상으로 하는 Active Directory의 계정은 DA(Do기본 관리s), EA(Enterprise 관리) 또는 Active Directory의 기본 제공 BA(관리istrators) 그룹의 구성원과 같이 가장 권한이 높은 그룹의 구성원입니다. 이러한 그룹의 공격 노출 영역이 제한되도록 이러한 그룹의 멤버 자격을 가능한 가장 적은 수의 계정으로 줄여야 합니다. 이러한 권한 있는 그룹에서 "영구" 멤버 자격을 제거할 수도 있습니다. 즉, 해당 수행기본 및 포리스트 전체 권한이 필요한 경우에만 이러한 그룹을 일시적으로 채울 수 있는 설정을 구현할 수 있습니다. 높은 권한이 있는 계정을 사용하는 경우 컨트롤러 또는 보안 관리 호스트와 같은 지정된 보안 시스템에서만 사용해야 기본. 이러한 모든 구성을 구현하는 데 도움이 되는 자세한 정보는 Active Directory 공격 표면 축소에 제공됩니다.

Active Directory에서 가장 높은 권한 있는 그룹의 멤버 자격을 평가할 때 일반적으로 가장 권한이 높은 세 그룹 모두에 과도한 멤버 자격이 있습니다. 경우에 따라 조직에는 DA 그룹에 수십 개의 계정, 심지어 수백 개의 계정이 있습니다. 다른 경우에는 조직이 DAS 그룹보다 "권한이 적다"고 생각하여 기본 제공 관리istrators 그룹에 직접 계정을 배치합니다. 그것이 아니야. EA 권한이 거의 및 일시적으로 필요하지는 않으므로 포리스트 루트에 있는 EA 그룹의 영구 멤버가 기본 경우가 많습니다. 세 그룹 모두에서 IT 사용자의 일상적인 관리 계정을 찾는 것도 일반적입니다. 이는 사실상 중복된 구성임에도 불구하고 일반적입니다. Active Directory 공격 표면 축소에 설명된 대로 계정이 이러한 그룹 중 하나의 영구 멤버인지 아니면 모든 그룹의 영구 멤버인지에 관계없이 계정을 사용하여 AD DS 환경과 AD DS 환경 및 관리되는 시스템 및 계정을 손상시킬 수도 있습니다. Active Directory 에서 권한 있는 계정의 보안 구성 및 사용에 대한 권장 사항Active Directory 공격 노출 영역을 줄입니다.

할 일기본 컨트롤러

기본 컨트롤러를 평가할 때, 컨트롤러는 멤버 서버와 다르게 구성되고 관리되지 않는 경우가 많습니다. 기본 컨트롤러는 할 일기본 컨트롤러에 필요하기 때문이 아니라 애플리케이션이 표준 빌드의 일부이기 때문에 멤버 서버에 설치된 동일한 애플리케이션 및 유틸리티를 실행하는 경우가 있습니다. 이러한 애플리케이션은 do기본 컨트롤러에서 최소한의 기능을 제공할 수 있지만, 인증 및 그룹 정책 애플리케이션 이외의 용도로 do기본 컨트롤러에 연결해서는 안 되는 사용자가 포트를 열거나, 권한이 높은 서비스 계정을 만들거나, 시스템에 대한 액세스 권한을 부여하는 구성 설정을 요구하여 공격 화면에 크게 추가할 수 있습니다. 일부 위반에서 공격자는 do기본 컨트롤러에 이미 설치된 도구를 사용하여 do기본 컨트롤러에 액세스할 뿐만 아니라 AD DS 데이터베이스를 수정하거나 손상시켰습니다.

do기본 컨트롤러에서 Internet Explorer 구성 설정을 추출할 때 사용자가 Active Directory에서 높은 수준의 권한을 가진 계정으로 로그온했으며 계정을 사용하여 할 일기본 컨트롤러에서 인터넷 및 인트라넷에 액세스한 것을 확인할 수 있습니다. 경우에 따라 계정은 인터넷 콘텐츠 다운로드를 허용하도록 do기본 컨트롤러에서 Internet Explorer 설정을 구성했으며, 프리웨어 유틸리티는 인터넷 사이트에서 다운로드되어 할 일기본 컨트롤러에 설치되었습니다. Internet Explorer 보안 강화 구성은 기본적으로 사용자 및 관리에 대해 사용하도록 설정되어 있지만 관리 작성자에 대해 사용하지 않도록 설정된 경우가 많습니다. 높은 권한의 계정이 인터넷에 액세스하고 모든 컴퓨터에 콘텐츠를 다운로드하면 해당 컴퓨터는 심각한 위험에 처하게 됩니다. 컴퓨터가 할 일기본 컨트롤러인 경우 전체 AD DS 설치가 위험에 처하게 됩니다.

Do기본 컨트롤러 보호

할기본 컨트롤러는 파일, 인쇄 및 애플리케이션 서버보다 더 엄격하게 보호되고 더 엄격하게 구성된 중요한 인프라 구성 요소로 취급되어야 합니다. do기본 컨트롤러는 do기본 컨트롤러가 작동하는 데 필요하지 않거나 공격으로부터 do기본 컨트롤러를 보호하지 않는 소프트웨어를 실행해서는 안 됩니다. do기본 컨트롤러는 인터넷에 액세스하도록 허용해서는 안 되며, GPO(그룹 정책 개체)에서 보안 설정을 구성하고 적용해야 합니다. do기본 컨트롤러의 보안 설치, 구성 및 관리에 대한 자세한 권장 사항은 공격에 대한 보안 Do기본 컨트롤러에 제공됩니다.

운영 체제 내

법 번호 2: 악의적인 사람이 컴퓨터의 운영 체제를 변경할 수 있는 경우 더 이상 컴퓨터가 아닙니다. - 변경할 수 없는 10가지 보안법(버전 2.0)

일부 조직에서는 다양한 유형의 서버에 대한 기준 구성을 만들고 운영 체제가 설치된 후 제한된 사용자 지정을 허용하지만 손상된 환경을 분석하면 종종 임시 방식으로 배포되고 수동으로 독립적으로 구성된 많은 수의 서버가 발견됩니다. 동일한 기능을 수행하는 두 서버 간의 구성은 완전히 다를 수 있으며, 두 서버 모두 안전하게 구성되지 않습니다. 반대로 서버 구성 기준은 일관되게 적용될 수 있지만 일관되게 잘못 구성될 수도 있습니다. 즉, 서버는 지정된 형식의 모든 서버에서 동일한 취약성을 만드는 방식으로 구성됩니다. 잘못된 구성에는 보안 기능 사용 안 함, 계정(특히 서비스 계정)에 대한 과도한 권한 및 권한 부여, 시스템 간에 동일한 로컬 자격 증명 사용, 자체 취약성을 만드는 권한 없는 애플리케이션 및 유틸리티 설치 허용과 같은 관행이 포함됩니다.

보안 기능 사용 안 함과

조직에서는 WFAS를 구성하기 어렵거나 작업 집약적인 구성이 필요하다는 믿음 때문에 WFAS(Advanced Security)를 사용하는 Windows 방화벽을 사용하지 않도록 설정하는 경우가 있습니다. 그러나 Windows Server 2008부터 서버에 역할 또는 기능이 설치된 경우 기본적으로 역할 또는 기능이 작동하는 데 필요한 최소 권한으로 구성되며 Windows 방화벽은 역할 또는 기능을 지원하도록 자동으로 구성됩니다. WFAS를 사용하지 않도록 설정하여(그리고 그 자리에 다른 호스트 기반 방화벽을 사용하지 않음) 조직은 전체 Windows 환경의 공격 노출 영역을 늘립니다. 경계 방화벽은 인터넷에서 환경을 직접 대상으로 하는 공격으로부터 일부 보호를 제공하지만, 드라이브 바이 다운로드 공격과 같은 다른 공격 벡터를 악용하는 공격이나 인트라넷의 다른 손상된 시스템에서 발생한 공격에 대한 보호를 제공하지 않습니다.

관리자가 프롬프트가 방해가 되는 것을 발견하기 때문에 서버에서 UAC(사용자 계정 컨트롤) 설정을 사용하지 않도록 설정해야 하는 경우가 있습니다. Microsoft 지원 문서 2526083 Windows Server에서 UAC를 사용하지 않도록 설정할 수 있는 시나리오에 대해 설명하지만, 서버 코어 설치(UAC가 의도적으로 비활성화된 경우)를 실행하지 않는 한 신중하게 고려하고 조사하지 않고 서버에서 UAC를 사용하지 않도록 설정해서는 안 됩니다.

다른 경우에는 조직에서 Windows Server 2012, Windows Server 2008 R2 또는 Windows Server 2008을 실행하는 컴퓨터에 Windows Server 2003 기준을 적용하는 등 운영 체제의 변경 내용을 반영하도록 기준을 변경하지 않고도 오래된 서버 구성 설정을 새 운영 체제에 적용하기 때문에 서버 설정이 덜 안전한 값으로 구성됩니다. 새 운영 체제에 이전 서버 기준을 전달하는 대신 새 운영 체제를 배포할 때 보안 변경 내용 및 구성 설정을 검토하여 구현된 설정이 새 운영 체제에 적용 가능하고 적절한지 확인합니다.

과도한 권한 부여

평가한 거의 모든 환경에서 과도한 권한은 Windows 시스템에서 로컬 및 do기본 기반 계정에 부여됩니다. 사용자에게 워크스테이션에 대한 로컬 관리이용자 권한이 부여되고, 멤버 서버는 작동하는 데 필요한 것 이상으로 권한으로 구성된 서비스를 실행하고, 서버 모집단의 로컬 관리주체 그룹에는 수십 또는 수백 개의 로컬 및 할기본 계정이 포함됩니다. 컴퓨터에서 하나의 권한 있는 계정만 손상하면 공격자가 컴퓨터에 로그온하는 모든 사용자 및 서비스의 계정을 손상하고 자격 증명을 수집하여 다른 시스템에 손상이 전파되도록 할 수 있습니다.

현재 PTH(Pass-the-Hash) 및 기타 자격 증명 도난 공격은 유비쿼터스이지만 공격자가 컴퓨터에 대한 관리istrator 또는 SYSTEM 수준 액세스 권한을 얻었을 때 다른 권한 있는 계정의 자격 증명을 간단하고 쉽게 추출할 수 있는 자유롭게 사용할 수 있는 도구가 있기 때문입니다. 로그온 세션에서 자격 증명을 수집할 수 있는 도구가 없더라도 컴퓨터에 대한 권한 있는 액세스 권한이 있는 공격자는 키 입력, 스크린샷 및 클립보드 콘텐츠를 캡처하는 키 입력 로거를 쉽게 설치할 수 있습니다. 컴퓨터에 대한 권한 있는 액세스 권한이 있는 공격자는 맬웨어 방지 소프트웨어를 사용하지 않도록 설정하거나, 루트킷을 설치하거나, 보호된 파일을 수정하거나, 공격을 자동화하거나 서버를 드라이브 바이 다운로드 호스트로 바꾸는 맬웨어를 컴퓨터에 설치할 수 있습니다.

단일 컴퓨터 이상으로 위반을 확장하는 데 사용되는 전술은 다양하지만, 타협을 전파하는 열쇠는 추가 시스템에 대한 높은 권한의 액세스를 획득하는 것입니다. 모든 시스템에 대한 권한 있는 액세스 권한이 있는 계정 수를 줄이면 해당 컴퓨터의 공격 노출 영역뿐만 아니라 공격자가 컴퓨터에서 중요한 자격 증명을 수집할 가능성을 줄일 수 있습니다.

로컬 관리사용자 자격 증명 표준화

Windows 컴퓨터에서 로컬 관리istrator 계정의 이름을 바꾸는 데 가치가 있는지에 대한 보안 전문가 간의 논쟁이 오랫동안 있었습니다. 로컬 관리istrator 계정에서 실제로 중요한 것은 여러 컴퓨터에서 동일한 사용자 이름 및 암호로 구성되었는지 여부입니다.

로컬 관리istrator 계정이 서버에서 동일한 값으로 명명되고 계정에 할당된 암호도 동일한 값으로 구성된 경우 공격자는 관리이스트레이터 또는 시스템 수준 액세스가 얻은 한 컴퓨터에서 계정의 자격 증명을 추출할 수 있습니다. 공격자는 처음에는 관리이스트레이터 계정을 손상시킬 필요가 없습니다. 로컬 관리이스트래터 그룹의 구성원인 사용자 또는 LocalSystem 또는 관리istrator 권한으로 실행되도록 구성된 서비스 계정만 손상해야 합니다. 그런 다음 공격자는 관리istrator 계정에 대한 자격 증명을 추출하고 네트워크 로그온에서 해당 자격 증명을 네트워크의 다른 컴퓨터로 재생할 수 있습니다.

다른 컴퓨터에 표시되는 계정 자격 증명과 동일한 사용자 이름 및 암호(또는 암호 해시)를 가진 로컬 계정이 있는 한 로그온 시도가 성공하고 공격자가 대상 컴퓨터에 대한 권한 있는 액세스 권한을 얻습니다. 현재 버전의 Windows에서는 기본 제공 관리istrator 계정이 기본적으로 사용하지 않도록 설정되어 있지만 레거시 운영 체제에서는 기본적으로 계정이 사용하도록 설정됩니다.

참고 항목

일부 조직에서는 다른 모든 권한 있는 계정이 시스템에서 잠긴 경우 "failafe"를 제공한다는 신념으로 로컬 관리이스트레이터 계정을 사용하도록 의도적으로 구성했습니다. 그러나 로컬 관리istrator 계정이 비활성화되어 있고 관리제공자 권한으로 계정을 사용하도록 설정하거나 시스템에 로그온할 수 있는 다른 계정이 없더라도 시스템을 안전 모드로 부팅할 수 있으며 Microsoft 지원 문서 814777 설명한 대로 기본 제공 로컬 관리istrator 계정을 다시 사용하도록 설정할 수 있습니다. 또한 시스템에서 여전히 GPO를 성공적으로 적용하는 경우 GPO를 수정하여 (일시적으로) 관리주체 계정을 다시 사용하도록 설정하거나, 로컬 관리istrators 그룹에 do기본 기반 계정을 추가하도록 제한된 그룹을 구성할 수 있습니다. 복구를 수행할 수 있으며 관리istrator 계정을 다시 사용하지 않도록 설정할 수 있습니다. 기본 제공 로컬 관리istrator 계정 자격 증명을 사용하는 횡적 손상을 효과적으로 방지하려면 로컬 관리istrator 계정에 대해 고유한 사용자 이름 및 암호를 구성해야 합니다. GPO를 통해 로컬 관리istrator 계정에 대한 고유 암호를 배포하려면 technet의 GPO를 통해 기본 제공 관리istrator 계정의 암호를 관리하기 위한 솔루션을 참조하세요.  

권한 없는 애플리케이션 설치 허용

법 번호 1 : 나쁜 사람이 당신의 컴퓨터에서 자신의 프로그램을 실행하도록 설득 할 수 있다면, 그것은 더 이상 당신의 컴퓨터만 아니다. - 변경할 수 없는 10가지 보안법(버전 2.0)

조직에서 서버 간에 일관된 기준 설정을 배포하는지 여부에 관계없이 서버의 정의된 역할에 속하지 않는 애플리케이션의 설치는 허용되지 않아야 합니다. 서버의 지정된 기능에 속하지 않는 소프트웨어를 설치할 수 있도록 허용하면 서버가 서버의 공격 표면을 증가하거나, 애플리케이션 취약성을 발생하거나, 시스템 불안정을 야기하는 소프트웨어의 의도치 않거나 악의적인 설치에 노출됩니다.

애플리케이션

앞에서 설명한 대로 애플리케이션은 애플리케이션에 실제로 필요한 것보다 더 많은 권한이 부여된 계정을 사용하도록 종종 설치 및 구성됩니다. 경우에 따라 애플리케이션의 설명서에서는 서비스 계정이 서버의 로컬 관리istrators 그룹의 멤버이거나 LocalSystem의 컨텍스트에서 실행되도록 구성해야 한다고 지정합니다. 이는 애플리케이션에 이러한 권한이 필요하기 때문이 아니라 애플리케이션의 서비스 계정에 필요한 권한과 권한을 결정하려면 추가 시간과 노력에 투자해야 하기 때문입니다. 애플리케이션이 작동하는 데 필요한 최소 권한 및 구성된 기능으로 애플리케이션을 설치하지 않으면 운영 체제 자체에 대한 공격 없이 애플리케이션 권한을 활용하는 공격에 시스템이 노출됩니다.

보안 애플리케이션 개발 방법 부족

비즈니스 워크로드를 지원하기 위한 인프라가 있습니다. 이러한 워크로드가 사용자 지정 애플리케이션에서 구현되는 경우 보안 모범 사례를 사용하여 애플리케이션을 개발하는 것이 중요합니다. 엔터프라이즈 전체 인시던트에 대한 근본 원인 분석은 사용자 지정 애플리케이션, 특히 인터넷에 연결된 애플리케이션을 통해 초기 손상이 영향을 받는 경우가 많습니다. 이러한 손상의 대부분은 SQLi(SQL 삽입) 및 XSS(교차 사이트 스크립팅) 공격과 같은 잘 알려진 공격을 손상하여 수행됩니다.

SQL 삽입은 사용자 정의 입력이 실행을 위해 데이터베이스에 전달되는 SQL 문을 수정할 수 있도록 하는 애플리케이션 취약성입니다. 이 입력은 애플리케이션의 필드, 매개 변수(예: 쿼리 문자열 또는 쿠키) 또는 기타 메서드를 통해 제공할 수 있습니다. 이 삽입의 결과는 데이터베이스에 제공된 SQL 문이 개발자가 의도한 것과 근본적으로 다르다는 것입니다. 예를 들어 사용자 이름/암호 조합의 평가에 사용되는 일반적인 쿼리를 사용합니다.

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

데이터베이스 서버에서 이를 수신하면 서버에서 사용자 테이블을 살펴보고 사용자 이름과 암호가 사용자가 제공한 레코드와 일치하는 userID 레코드를 반환하도록 지시합니다(아마도 어떤 종류의 로그인 형식을 통해). 이 경우 개발자의 의도는 사용자가 올바른 사용자 이름과 암호를 제공할 수 있는 경우에만 유효한 레코드를 반환하는 것입니다. 둘 중 하나가 올바르지 않으면 데이터베이스 서버에서 일치하는 레코드를 찾고 빈 결과를 반환할 수 없습니다.

이 문제는 공격자가 유효한 데이터 대신 자체 SQL을 제공하는 등 예기치 않은 작업을 수행할 때 발생합니다. SQL은 데이터베이스 서버에서 즉석에서 해석되므로 삽입된 코드는 개발자가 직접 배치한 것처럼 처리됩니다. 예를 들어 공격자가 사용자 ID 및 xyz OR 1=1에 대한 관리자를 암호로 입력한 경우 데이터베이스에서 처리한 결과 문은 다음과 같습니다.

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

데이터베이스 서버에서 이 쿼리를 처리하면 1=1이 항상 True로 평가되므로 테이블의 모든 행이 쿼리에 반환되므로 올바른 사용자 이름과 암호가 알려지거나 제공되었는지는 중요하지 않습니다. 대부분의 경우 순 결과는 사용자가 사용자의 데이터베이스에서 첫 번째 사용자로 로그온된다는 것입니다. 대부분의 경우 관리자가 됩니다.

단순히 로그온하는 것 외에도 이와 같은 형식이 잘못된 SQL 문을 사용하여 데이터를 추가, 삭제 또는 변경하거나 데이터베이스에서 전체 테이블을 삭제(삭제)할 수도 있습니다. SQLi가 과도한 권한과 결합되는 가장 극단적인 경우 운영 체제 명령을 실행하여 새 사용자를 만들거나, 공격 도구를 다운로드하거나, 선택한 공격자의 다른 작업을 수행할 수 있습니다.

사이트 간 스크립팅에서 취약성은 애플리케이션의 출력에 도입됩니다. 공격은 공격자가 애플리케이션에 잘못된 형식의 데이터를 제공하는 것으로 시작하지만, 이 경우 잘못된 형식의 데이터는 피해자의 브라우저에서 실행할 스크립팅 코드(예: JavaScript)의 형태입니다. XSS 취약성을 악용하면 공격자가 브라우저를 시작한 사용자의 컨텍스트에서 대상 애플리케이션의 모든 기능을 실행할 수 있습니다. XSS 공격은 일반적으로 사용자가 애플리케이션에 연결하고 공격 코드를 실행하는 링크를 선택하도록 권장하는 피싱 메일에 의해 시작됩니다.

XSS는 공격자가 악용된 사용자의 컨텍스트에서 구매하거나 송금할 수 있는 온라인 뱅킹 및 전자 상거래 시나리오에서 악용되는 경우가 많습니다. 사용자 지정 웹 기반 ID 관리 애플리케이션에 대한 대상 공격의 경우 공격자가 자신의 ID를 만들고, 권한 및 권한을 수정하고, 시스템 손상으로 이어질 수 있습니다.

사이트 간 스크립팅 및 SQL 삽입에 대한 전체 설명은 이 문서의 범위를 벗어나지만 OWASP (Open Web Application Security Project) 는 취약성 및 대책에 대한 심층적인 논의가 포함된 상위 10개 목록을 게시합니다.

인프라 보안에 대한 투자와 관계없이 제대로 설계되지 않은 애플리케이션과 작성된 애플리케이션이 해당 인프라 내에 배포되는 경우 환경은 공격에 취약합니다. 잘 보호된 인프라조차도 이러한 애플리케이션 공격에 대한 효과적인 대책을 제공할 수 없는 경우가 많습니다. 문제가 복잡해지면 제대로 디자인되지 않은 애플리케이션은 서비스 계정에 애플리케이션이 작동할 수 있는 과도한 권한을 부여해야 할 수 있습니다.

Microsoft SDL(보안 개발 수명 주기)은 서비스 해제될 때까지 애플리케이션의 수명 주기를 수집하고 확장하는 요구 사항의 초기부터 보안을 개선하기 위해 작동하는 구조적 프로세스 제어 집합입니다. 효과적인 보안 제어의 통합은 보안 관점에서 중요할 뿐만 아니라 애플리케이션 보안이 비용 및 일정 효율성을 보장하는 것이 중요합니다. 효과적으로 코드가 완료될 때 보안 문제에 대한 애플리케이션을 평가하려면 조직에서 애플리케이션이 배포되기 전이나 후에만 애플리케이션 보안에 대한 결정을 내려야 합니다. 조직은 프로덕션 환경에서 애플리케이션을 배포하기 전에 애플리케이션 결함을 해결하도록 선택할 수 있으며, 비용과 지연이 발생하거나 알려진 보안 결함으로 프로덕션 환경에 애플리케이션을 배포하여 조직이 손상될 수 있습니다.

일부 조직에서는 문제당 10,000달러 이상의 프로덕션 코드에서 보안 문제를 해결하는 데 드는 전체 비용을 부담하며, 효과적인 SDL 없이 개발된 애플리케이션은 코드 100,000줄당 평균 10개 이상의 심각도 문제를 초과할 수 있습니다. 대규모 애플리케이션에서는 비용이 빠르게 증가합니다. 반면, 많은 회사는 SDL의 최종 코드 검토 단계에서 코드 줄 100,000개당 1개 미만의 문제의 벤치마크를 설정하고 프로덕션에서 위험도가 높은 애플리케이션에서 0개의 문제를 목표로 합니다.

SDL을 구현하면 애플리케이션의 요구 사항 수집 및 설계 초기에 보안 요구 사항을 포함하여 보안이 향상되며, 위험 수준이 높은 애플리케이션에 대한 위협 모델링이 제공됩니다. 에는 개발자의 효과적인 교육 및 모니터링이 필요합니다. 명확하고 일관된 코드 표준 및 사례가 필요합니다. SDL의 순효과는 애플리케이션의 개발, 배포, 기본 및 서비스 해제 비용을 줄이면서 애플리케이션 보안이 크게 향상되었습니다. SDL의 디자인 및 구현에 대한 자세한 내용은 이 문서의 범위를 벗어나지만 자세한 지침과 정보는 Microsoft 보안 개발 수명 주기를 참조하세요.