앱 동의 부여 조사

이 문서에서는 앱 동의 공격 식별 및 조사, 정보 보호 및 추가 위험 최소화에 대한 지침을 제공합니다.

이 문서에는 다음과 같은 섹션이 포함되어 있습니다.

• 필수 구성 요소: 조사를 시작하기 전에 완료해야 하는 특정 요구 사항을 다룹니다. 예를 들어 설정해야 하는 로깅, 역할 및 사용 권한이 필요합니다.
• 워크플로: 이 조사를 수행하기 위해 따라야 하는 논리적 흐름을 표시합니다.
• 검사 목록: 흐름도의 각 단계에 대한 작업 목록을 포함합니다. 이 검사 목록은 높은 규제 환경에서 수행된 단계를 확인하거나 단순히 자신을 위한 품질 게이트로 확인하는 데 유용할 수 있습니다.
• 조사 단계: 이 특정 조사에 대한 자세한 단계별 지침을 포함합니다.
• 복구: 불법 애플리케이션 동의 부여 공격으로부터 복구/완화하는 방법에 대한 개략적인 단계를 포함합니다.
• 참조: 더 많은 읽기 및 참조 자료를 포함합니다.

필수 조건

다음은 애플리케이션 동의 권한 부여에 대한 조사를 수행할 때 완료해야 하는 일반적인 설정 및 구성입니다. 조사를 시작하기 전에 동의 권한 유형에 설명된 동의 권한 유형에 대해 읽어야 합니다.

고객 데이터

조사 프로세스를 시작하려면 다음 데이터가 필요합니다.

• 손상 지표의 세부 정보(IoC)
• 인시던트가 발생한 날짜 및 시간
• 날짜 범위
• 손상된 계정 수
• 손상된 계정의 이름
• 손상된 계정의 역할
• 계정이 높은 권한이 있나요(GA Microsoft Exchange, SharePoint)?
• 인시던트 관련 엔터프라이즈 애플리케이션이 있나요?
• 사용자가 대신 데이터에 대한 사용 권한을 요청한 애플리케이션을 보고했나요?

시스템 요구 사항

다음 설치 및 구성 요구 사항을 완료해야 합니다.

• AzureAD PowerShell 모듈이 설치됩니다.
• 스크립트가 실행되는 테넌트에 대한 전역 관리자 권한이 있습니다.
• 스크립트를 실행하는 데 사용하는 컴퓨터에 로컬 관리자 역할이 할당됩니다.

참고 항목

Azure AD와 MSOnline PowerShell 모듈은 2024년 3월 30일부터 더 이상 사용되지 않습니다. 자세히 알아보려면 사용 중단 업데이트를 참조하세요. 이 날짜 이후에는 이러한 모듈에 대한 지원이 Microsoft Graph PowerShell SDK 및 보안 수정 사항에 대한 마이그레이션 지원으로 제한됩니다. 사용되지 않는 모듈은 2025년 3월 30일까지 계속 작동합니다.

Microsoft Graph PowerShell로 마이그레이션하여 Microsoft Entra ID(이전의 Azure AD)와 상호 작용하는 것이 좋습니다. 일반적인 마이그레이션 관련 질문은 마이그레이션 FAQ를 참조하세요. 참고 항목: MSOnline 버전 1.0.x는 2024년 6월 30일 이후 중단될 수 있습니다.

AzureAD 모듈 설치

이 명령을 사용하여 AzureAD 모듈을 설치합니다.

Install-Module -Name AzureAD -Verbose

참고 항목

신뢰할 수 없는 리포지토리에서 모듈을 설치하라는 메시지가 표시되면 Y를 입력하고 Enter 키를 누릅니다.

MSOnline PowerShell 모듈 설치

1. 상승된 권한으로 Windows PowerShell 앱을 실행합니다(관리자 권한으로 실행).

2. 이 명령을 실행하여 PowerShell에서 서명된 스크립트를 실행할 수 있도록 합니다.

   Set-ExecutionPolicy RemoteSigned
   

3. 이 명령을 사용하여 MSOnline 모듈을 설치합니다.

   Install-Module -Name MSOnline -Verbose
   

   참고 항목

   신뢰할 수 없는 리포지토리에서 모듈을 설치하라는 메시지가 표시되면 Y를 입력하고 Enter 키를 누릅니다.

GitHub에서 AzureADPSPermissions 스크립트 다운로드

1. GitHub에서 스크립트를 실행하는 폴더로 Get-AzureADPSPermissions.ps1 스크립트를 다운로드합니다. 출력 파일 "permissions.csv"도 이 동일한 폴더에 기록됩니다.

2. 관리자 권한으로 PowerShell 인스턴스를 열고 스크립트를 저장한 폴더를 엽니다.

3. Connect-AzureAD cmdlet을 사용하여 디렉터리에 연결합니다. 예를 들어 다음과 같습니다.

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

4. 이 PowerShell 명령을 실행합니다.

   Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation
   

   이 명령을 사용하여 AzureAD 세션을 연결 해제합니다.

   Disconnect-AzureAD
   

동의 용어

애플리케이션 동의 부여란?

동의는 사용자를 대신하여 보호된 리소스에 액세스하기 위해 애플리케이션에 권한을 부여하는 프로세스입니다. 관리자 또는 사용자에게 조직/개별 데이터에 대한 액세스를 허용하는 데 동의를 요청할 수 있습니다.

애플리케이션에는 특정 사용자 또는 전체 조직에 따라 데이터에 대한 액세스 권한이 부여됩니다. 공격자는 이러한 동의를 오용하여 환경에 대한 지속성을 얻고 중요한 데이터에 액세스할 수 있습니다. 이러한 유형의 공격을 피싱 이메일, 암호 스프레이를 통한 사용자 계정 손상 또는 공격자가 애플리케이션을 합법적인 사용자로 등록할 때 발생할 수 있는 불법 동의 부여라고 합니다. 관리자 계정이 손상된 시나리오에서 등록 및 동의 부여는 한 사용자만 사용하는 것이 아니라 테넌트 전체에 대한 것입니다.

애플리케이션에서 조직의 데이터에 액세스하려면 먼저 사용자가 애플리케이션에 이 작업을 수행할 수 있는 권한을 부여해야 합니다. 여러 권한은 서로 다른 수준의 액세스를 허용합니다. 기본적으로 모든 사용자는 관리자의 동의가 필요하지 않은 권한을 애플리케이션에 부여하는 데 동의할 수 있습니다. 예를 들어, 사용자는 기본적으로 앱이 사서함에 액세스하는 데 동의할 수 있지만 앱이 조직의 모든 파일에 대한 읽기 및 쓰기 작업을 수행할 수 있는 무제한 액세스를 통해 허용하는 데 동의할 수 없습니다.

참고 항목

사용자가 앱에 데이터에 대한 액세스 권한을 부여하도록 허용하면 사용자가 유용한 애플리케이션을 손쉽게 획득하고 생산성을 높일 수 있습니다. 그러나 일부 상황에서는 이 구성이 신중하게 모니터링 및 제어되지 않는 경우 위험을 나타낼 수 있습니다.

조직을 대신하여 동의를 부여할 수 있는 역할

테넌트 전체 관리자 동의를 부여하려면 다음 역할 중 하나 이상을 사용하여 로그인해야 합니다.

• 애플리케이션 관리자
• 클라우드 애플리케이션 관리자

동의 유형

• 관리자 - 관리자가 동의를 제공했음을 나타냅니다(조직 대신).
• 개별 사용자 - 사용자가 동의를 부여했으며 해당 사용자의 정보에만 액세스할 수 있음을 나타냅니다.
• 허용되는 값
  • AllPrincipals - 전체 테넌트 관리자의 동의
  • 보안 주체 – 해당 계정과 관련된 데이터에 대해서만 개별 사용자가 동의

동의 및 사용 권한

동의를 부여하는 실제 사용자 환경은 사용자의 테넌트에 설정된 정책, 사용자의 권한 범위(또는 역할) 및 클라이언트 애플리케이션에서 요청한 사용 권한 유형에 따라 다릅니다. 즉, 애플리케이션 개발자와 테넌트 관리자는 동의 환경을 어느 정도 제어할 수 있습니다. 관리자는 테넌트 또는 앱에서 정책을 유연하게 설정하고 비활성화하여 테넌트의 동의 환경을 제어할 수 있습니다. 애플리케이션 개발자는 요청된 권한 유형과 사용자 동의 흐름 또는 관리자 동의 흐름을 통해 사용자를 안내하려는 경우 지정할 수 있습니다.

• 사용자 동의 흐름 - 애플리케이션 개발자가 현재 사용자만의 동의를 기록하려는 목적으로 권한 부여 엔드포인트로 사용자를 안내하는 경우입니다.

• 관리자 동의 흐름 - 애플리케이션 개발자가 전체 테넌트에 대한 동의를 기록하려는 의도로 사용자를 관리자 동의 엔드포인트로 안내하는 경우 관리자 동의 흐름이 제대로 작동되도록 하려면 애플리케이션 개발자는 애플리케이션 매니페스트의 RequiredResourceAccess 속성에서 모든 사용 권한을 나열해야 합니다.

위임된 권한과 애플리케이션 사용 권한 비교

위임된 권한은 로그인한 사용자가 있고 관리자 또는 사용자가 동의를 적용할 수 있는 앱에서 사용됩니다.

애플리케이션 권한은 로그인한 사용자가 없는 앱에서 사용합니다. 예를 들어, 백그라운드 서비스 또는 디먼으로 실행되는 앱입니다. 애플리케이션 권한은 관리자만 동의할 수 있습니다.

자세한 내용은 다음을 참조하세요.

• 특정 애플리케이션에 대한 관리자 승인에 대한 관리자 동의 워크플로
• 게시자 확인 프로그램
• 최종 사용자가 애플리케이션에 동의하는 방법 구성

위험한 권한 분류

시스템에는 (최소) 수천 개의 권한이 있으며 이러한 권한을 모두 나열하거나 구문 분석할 수 없습니다. 다음 목록에서는 일반적으로 오용되는 사용 권한 및 오용될 경우 치명적인 영향을 주는 기타 권한을 다룹니다.

높은 수준에서 Microsoft는 동의 피싱 공격에서 다음과 같은 "루트" 위임(App+User) 권한이 오용되는 것을 관찰했습니다. 루트는 최상위 수준과 동일합니다. 예를 들어 Contacts.* 는 연락처 권한 의 위임된 순열을 모두 포함하는 것을 의미합니다. Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared 및 Contacts.ReadWrite.Shared입니다.

1. Mail.* (Mail.Send*를 포함하지만 Mail.ReadBasic*은 포함되지 않음)
2. 연락처. *
3. MailboxSettings.*
4. 사람.*
5. 파일.*
6. 노트.*
7. Directory.AccessAsUser.All
8. User_Impersonation

이전 목록의 처음 7개 권한은 Microsoft Graph 및 Azure AD(Azure Active Directory) Graph 및 Outlook REST와 같은 "레거시" API에 해당합니다. 여덟 번째 권한은 ARM(Azure Resource Manager)에 대한 것이며 이 일괄 가장 범위로 중요한 데이터를 노출하는 모든 API에서도 위험할 수 있습니다.

Microsoft 인시던트 대응 팀의 관찰에 따라 공격자는 동의 피싱 공격의 99%에서 처음 6개의 사용 권한을 조합하여 사용합니다. 대부분의 사람들은 Mail.Read 또는 Files.Read의 위임된 버전을 고위험 권한으로 생각하지 않지만, 실제로 위험한 권한에 동의할 수 있는 관리자에 대한 스피어 피싱보다는 공격이 일반적으로 광범위하고 최종 사용자를 대상으로 합니다. 이러한 "중요한" 수준의 영향 권한으로 앱을 버블하는 것이 좋습니다. 애플리케이션에 악의적인 의도가 없고 악의적인 행위자가 앱 ID를 손상하는 경우에도 전체 조직이 위험에 처할 수 있습니다.

가장 높은 위험 영향 권한을 사용하려면 다음에서 시작합니다.

• 해당되는 경우 위의 모든 권한의 애플리케이션 권한(AppOnly/AppRole) 버전

다음 권한의 위임 및 AppOnly 버전:

• Application.ReadWrite.All
• Directory.ReadWrite.All
• Domain.ReadWrite.All*
• EduRoster.ReadWrite.All*
• Group.ReadWrite.All
• Member.Read.Hidden*
• RoleManagement.ReadWrite.Directory
• User.ReadWrite.All*
• User.ManageCreds.All
• 쓰기 액세스를 허용하는 다른 모든 AppOnly 권한

가장 낮은 위험 영향 권한 목록은 다음에서 시작합니다.

• User.Read
• User.ReadBasic.All
• Open_id
• Email
• 프로필
• Offline_access(이 "가장 낮은 위험" 목록에 대한 다른 권한과 쌍을 이루는 경우에만)

사용 권한 보기

1. 사용 권한을 보려면 엔터프라이즈 애플리케이션의 등록 화면으로 이동합니다.

   

2. API 권한 보기를 선택합니다.

   

3. 권한 추가를 선택하면 다음 화면이 표시됩니다.

   

4. Microsoft Graph를 선택하여 다양한 유형의 사용 권한을 봅니다.

   

5. 등록된 애플리케이션에서 사용 중인 사용 권한 유형(위임된사용 권한 또는 애플리케이션사용 권한)을 선택합니다. 위의 이미지 에서 애플리케이션 권한이 선택됩니다.

6. EduRoster와 같은 위험 수준이 높은 영향 권한 중 하나를 검색할 수 있습니다.

   

7. EduRoster를 선택하고 사용 권한을 확장합니다.

   

8. 이제 이러한 권한을 할당하거나 검토할 수 있습니다.

   자세한 내용은 그래프 사용 권한입니다.

워크플로

[]

다음도 가능합니다.

• 앱 동의 부여 및 기타 인시던트 응답 플레이북 워크플로를 PDF로 다운로드합니다.
• 앱 동의 부여 및 기타 인시던트 대응 플레이북 워크플로를 Visio 파일로 다운로드합니다.

검사 목록

이 검사 목록을 사용하여 애플리케이션 동의 부여 유효성 검사를 수행합니다.

• 손상 지표(IoC)

  다음 손상 지표(IoC)를 확인합니다.

  • 언제 인시던트를 인지했는가?
  • 인시던트 날짜 범위(목표 게시물이 얼마나 남아 있나요?)
  • 손상된 계정 수
  • 손상된 계정의 이름
  • 손상된 계정의 역할
  • 손상된 계정이 높은 권한, 표준 사용자 또는 조합인가?

• Roles

  다음 역할을 할당받아야 합니다.

  • 스크립트를 실행하는 컴퓨터의 로컬 관리자 역할

• PowerShell 구성

  다음 단계를 사용하여 PowerShell 환경을 구성합니다.

  1. Azure AD PowerShell 모듈을 설치합니다.
  2. 관리자 권한으로 Windows PowerShell 앱을 실행합니다. (관리자 권한으로 실행).
  3. 서명된 스크립트를 실행하도록 PowerShell을 구성합니다.
  4. Get-AzureADPSPermissions.ps1 스크립트를 다운로드합니다.

• 조사 트리거

  • 계정 손상
  • 테넌트에서 수정된 앱 동의 설정
  • 경고/감사 이벤트 상태 이유 "위험한 애플리케이션"이 검색됨
  • 이상하게 보이는 애플리케이션을 발견했습니다.

앱 동의 부여 및 기타 인시던트 플레이북 검사 목록을 Excel 파일로 다운로드할 수도 있습니다.

조사 단계

다음 세 가지 방법을 사용하여 애플리케이션 동의 부여를 조사할 수 있습니다.

• Azure Portal
• PowerShell 스크립트
• Microsoft 보안 부조종사

참고 항목

Azure Portal 을 사용하면 지난 90일 동안 관리자 동의 권한 부여만 볼 수 있으며 이를 기반으로 PowerShell 스크립트 메서드를 사용하여 공격자가 조사 단계를 등록하는 것을 줄이는 것이 좋습니다.

방법 1 – Azure Portal 사용

Microsoft Entra 관리 센터를 사용하여 개별 사용자가 권한을 부여한 애플리케이션을 찾을 수 있습니다.

1. Azure Portal에 관리자로 로그인합니다.
2. Microsoft Entra ID 아이콘을 선택합니다.
3. 사용자를 선택합니다.
4. 검토할 사용자를 선택합니다.
5. 애플리케이션을 선택합니다.
6. 사용자에게 할당된 앱 목록과 이러한 애플리케이션의 사용 권한을 확인할 수 있습니다.

메서드 2 - PowerShell 사용

다음과 같은 불법 동의 부여를 조사하는 데 사용할 수 있는 몇 가지 PowerShell 도구가 있습니다.

• HAWK 도구
• AzureAD 인시던트 대응 모듈
• GitHub의 Get-AzureADPSPermissions.ps1 스크립트

PowerShell은 가장 쉬운 도구이며 테넌트의 모든 항목을 수정할 필요가 없습니다. 우리는 불법 동의 부여 공격의 공개 설명서에 대한 조사를 기반으로 할 것입니다.

를 실행Get-AzureADPSPermissions.ps1하여 테넌시의 모든 사용자에 대한 모든 OAuth 동의 권한 부여 및 OAuth 앱을 .csv 파일로 내보냅니다. 스크립트를 다운로드하고 실행하려면 필수 구성 요소 섹션을 Get-AzureADPSPermissions 참조하세요.

1. 관리자 권한으로 PowerShell 인스턴스를 열고 스크립트를 저장한 폴더를 엽니다.

2. 다음 Connect-AzureAD 명령을 사용하여 디렉터리에 연결합니다. 예를 들어 다음과 같습니다.

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

3. 이 PowerShell 명령을 실행합니다.

   Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation
   

4. 스크립트가 완료되면 이 명령을 사용하여 Microsoft Entra 세션의 연결을 끊는 것이 좋습니다.

    Disconnect-AzureAD
   

   참고 항목

   스크립트를 완료하는 데 몇 시간이 걸릴 수 있습니다. 이 스크립트는 구성한 크기와 사용 권한 및 연결에 따라 달라집니다.

5. 스크립트는 Permissions.csv라는 파일을 만듭니다.

6. 파일을 연 다음, 데이터를 테이블로 필터링하거나 서식을 지정하고 파일로 저장합니다 .xlxs .

   출력에 대한 열 머리글이 이 이미지에 표시됩니다.

   

7. ConsentType 열 (G)에서 AllPrinciples 값을 검색합니다. AllPrincipals 권한을 통해 클라이언트 애플리케이션은 테넌시의 모든 콘텐츠에 액세스할 수 있습니다. 기본 Microsoft 365 애플리케이션이 제대로 작동하려면 이 권한이 필요합니다. 이 권한이 있는 모든 비 Microsoft 애플리케이션은 신중하게 검토해야 합니다.

8. 권한 열(F)에서 위임된 각 애플리케이션의 사용 권한을 검토합니다. 읽기 및 쓰기 권한 또는 *를 찾습니다. 모든 사용 권한 및 적절하지 않을 수 있으므로 이러한 사용 권한을 신중하게 검토합니다.

   참고 항목

   동의가 부여된 특정 사용자를 검토합니다. 높은 프로필 또는 높은 영향을 미치는 사용자에게 부적절한 동의가 부여된 경우 추가로 조사해야 합니다.

9. ClientDisplayName 열(C)에서 다음과 같이 의심스러운 앱을 찾습니다.

   • 철자가 잘못된 이름의 앱

   • 비정상적이거나 단조로운 이름

   • 해커 소리 이름. 이러한 이름을 신중하게 검토해야 합니다.

예제 출력: AllPrincipals 및 읽기 쓰기 모두입니다. 애플리케이션에는 단조로운 이름과 같은 의심스러운 항목이 없을 수 있으며 MS 그래프를 사용하고 있습니다. 그러나 이 예제와 같이 조사를 수행하고 애플리케이션이 테넌트에 있는 애플리케이션의 목적과 실제 사용 권한을 결정합니다.

ISP(정보 보안 정책) 조사를 검토하기 위한 몇 가지 유용한 팁은 다음과 같습니다.

• ReplyURL/RedirectURL
  • 의심스러운 URL 찾기
• URL이 의심스러운 도메인에 호스트되나요?
  • 손상된가요?
  • 도메인이 최근에 등록되었나요?
  • 임시 도메인인가요?
• 앱 등록에 서비스 약관/서비스 계약 링크가 있나요?
• 콘텐츠가 고유하고 애플리케이션/게시자와 관련이 있나요?
• 애플리케이션을 등록한 테넌트가 새로 생성되었거나 손상되었는가(예: 위험한 사용자가 앱을 등록했는가)?

방법 3 - Microsoft Entra 관리 센터에서 보안 코필로트 사용

Microsoft Security Copilot사용하면 자연어 프롬프트를 사용하여 애플리케이션 또는 워크로드 ID와 관련된 위험을 식별하고 이해할 수 있습니다. 여기에는 Microsoft Entra 관리 센터에서 바로 부여된 권한 및 고급 권한이 포함됩니다. Microsoft Security Copilot을 사용하여 애플리케이션 위험을 평가하는 방법을 자세히 알아보세요.

동의 부여 공격에 대한 세부 정보

공격 기법

각 공격은 다양하지만 핵심 공격 기법은 다음과 같습니다.

• 공격자가 Microsoft Entra ID와 같은 OAuth 2.0 공급자에 앱을 등록합니다.

• 애플리케이션은 합법적인 것처럼 보이게 하는 방식으로 구성됩니다. 예를 들어 공격자는 동일한 에코시스템에서 사용할 수 있는 인기 제품의 이름을 사용할 수 있습니다.

• 공격자는 기존의 이메일 기반 피싱을 통해, 비해결 웹 사이트를 손상시키거나, 다른 기술을 통해 수행할 수 있는 사용자로부터 직접 링크를 가져옵니다.

• 사용자는 링크를 선택하고 데이터에 악의적인 앱 권한을 부여하도록 요청하는 본격적인 동의 프롬프트가 표시됩니다.

• 사용자가 '수락'을 선택하면 중요한 데이터에 액세스할 수 있는 권한을 앱에 부여합니다.

• 앱은 액세스 토큰에 사용되는 인증 코드와 새로 고침 토큰을 가져옵니다.

• 액세스 토큰은 사용자를 대신하여 API를 호출하는 데 사용됩니다.

• 사용자가 수락하는 경우 공격자는 사용자의 메일, 전달 규칙, 파일, 연락처, 메모, 프로필 및 기타 중요한 데이터 및 리소스에 액세스할 수 있습니다.

  

공격의 징후 찾기

1. Microsoft 365 Defender 포털에서 https://security.microsoft.com감사로 이동합니다. 또는 감사 페이지로 https://security.microsoft.com/auditlogsearch

2. 감사 페이지에서 모든 활동 및 모든 사용자를 검색하고 필요한 경우 시작 날짜와 종료 날짜를 입력한 다음 검색을 선택합니다.

   

3. 결과 필터링을 선택하고 활동 필드에서 애플리케이션에 동의를 입력합니다.

   

4. 허용에 동의한 활동이 있는 경우 다음 단계를 계속 진행합니다.

5. 결과를 선택하여 활동의 세부 정보를 확인합니다. 자세한 정보를 선택하여 활동에 대한 세부 정보를 가져옵니다.

6. IsAdminContent가 'True'로 설정되어 있는지 확인합니다.

   참고 항목

   이 프로세스는 이벤트가 발생한 후 해당 감사 로그 항목이 검색 결과에 표시되는 데 30분에서 24시간까지 걸릴 수 있습니다.

   감사 레코드가 유지되고 감사 로그에서 검색 가능한 시간은 Microsoft 365 구독, 특히 특정 사용자에게 할당된 라이선스 유형에 따라 달라집니다. 이 값이 true이면 누군가가 데이터에 대한 광범위한 액세스 권한을 부여했을 수 있음을 나타냅니다. 예기치 않은 경우 즉각적인 조치를 취하여 공격을 확인합니다.

공격을 확인하는 방법

이전에 나열된 IoC 인스턴스가 하나 이상 있는 경우 추가 조사를 수행하여 공격이 발생했는지 확인해야 합니다.

조직에서 액세스할 수 있는 인벤토리 앱

Microsoft Entra 관리 센터, PowerShell을 사용하여 사용자를 위한 앱 인벤토리를 만들거나 사용자가 애플리케이션 액세스를 개별적으로 열거할 수 있습니다.

• Microsoft Entra 관리 센터를 사용하여 애플리케이션 및 해당 사용 권한을 인벤토리로 만듭니다. 이 방법은 철저하지만 한 번에 한 명의 사용자만 확인할 수 있으므로 여러 사용자의 사용 권한을 확인해야 하는 경우 시간이 오래 걸릴 수 있습니다.
• PowerShell을 사용하여 애플리케이션 및 해당 사용 권한을 인벤토리로 작성합니다. 이 메서드는 오버헤드가 가장 적은 가장 빠르고 철저합니다.
• 사용자가 앱과 사용 권한을 개별적으로 확인하고 결과를 관리자에게 다시 보고하여 수정하도록 권장합니다.

사용자에게 할당된 인벤토리 앱

Microsoft Entra 관리 센터를 사용하여 개별 사용자가 권한을 부여한 앱 목록을 볼 수 있습니다.

1. 관리 권한으로 Azure Portal에 로그인합니다.
2. Microsoft Entra ID 아이콘을 선택합니다.
3. 사용자를 선택합니다.
4. 검토할 사용자를 선택합니다.
5. 애플리케이션을 선택합니다.

사용자에게 할당된 앱 목록과 이러한 앱에 부여된 사용 권한을 볼 수 있습니다.

공격 범위 확인

애플리케이션 액세스 인벤토리를 완료한 후 감사 로그를 검토하여 위반의 전체 범위를 확인합니다. 영향을 받는 사용자, 불법 애플리케이션이 조직에 액세스한 시간 프레임 및 앱이 가진 사용 권한을 검색합니다. Microsoft 365 보안 및 Microsoft Purview 규정 준수 포털 감사 로그를 검색할 수 있습니다.

Important

가능한 공격 전에 감사를 사용하도록 설정하지 않은 경우 감사 데이터를 사용할 수 없 으므로 조사할 수 없습니다.

공격을 방지하고 위험을 완화하는 방법

• 부당하거나 의심스러운 애플리케이션에 데이터에 대한 액세스 권한이 부여되지 않도록 조직에서 애플리케이션 및 부여된 권한을 정기적으로 감사합니다.

• Office 365에서 불법 동의 부여를 검토, 검색 및 수정합니다. OAuth 동의를 요청하는 의심스러운 애플리케이션에 대한 더 많은 모범 사례 및 보호

조직에 적절한 라이선스가 있는 경우 다음을 수행합니다.

• 클라우드용 Microsoft Defender 앱에서 더 많은 OAuth 애플리케이션 감사 기능을 사용합니다.
• Azure Monitor 통합 문서를 사용하여 사용 권한 및 동의 관련 활동을 모니터링합니다. 동의 Insights 통합 문서는 실패한 동의 요청 수에 따른 앱 보기를 제공합니다. 이는 관리자가 관리자 동의를 부여할지 여부를 검토하고 결정할 수 있도록 애플리케이션의 우선 순위를 지정하는 데 도움이 될 수 있습니다.

불법 동의 부여 공격을 중지하고 수정하는 방법

불법 권한이 있는 애플리케이션을 식별한 후 애플리케이션 사용 안 함의 지침에 따라 애플리케이션을 즉시 사용하지 않도록 설정합니다. 그런 다음 Microsoft 지원 문의하여 악의적인 애플리케이션을 보고합니다.

Microsoft Entra에서 애플리케이션을 사용하지 않도록 설정하면 데이터에 액세스하기 위한 새 토큰을 가져올 수 없으며 다른 사용자는 앱에 로그인하거나 동의를 부여할 수 없습니다.

참고 항목

조직에서 악의적인 애플리케이션이 발생한 것으로 의심되는 경우 삭제하는 것보다 사용하지 않도록 설정하는 것이 좋습니다. 애플리케이션만 삭제하는 경우 다른 사용자가 동의를 부여하면 나중에 반환될 수 있습니다. 대신 애플리케이션을 사용하지 않도록 설정하여 나중에 다시 돌아올 수 없도록 합니다.

권장 방어

조직을 보호하는 단계

다양한 동의 공격 유형이 있으며, 이러한 권장 방어는 모든 유형의 공격, 특히 공격자가 사용자를 속여 중요한 데이터 또는 기타 리소스에 대한 악의적인 앱 액세스 권한을 부여하도록 유도하는 모든 유형의 공격을 완화합니다. 공격자는 사용자의 암호를 도용하는 대신 공격자가 제어하는 앱이 중요한 데이터에 액세스할 수 있는 권한을 찾고 있습니다.

동의 공격이 Microsoft Entra ID 및 Office 365에 영향을 주지 않도록 하려면 다음 권장 사항을 참조하세요.

정책 설정

• 이 설정은 사용자에게 영향을 미치며 환경에 적용되지 않을 수 있습니다. 동의를 허용하려는 경우 관리자가 요청을 승인하는지 확인합니다.

• 확인된 게시자의 애플리케이션에 대해서만 동의하고 낮은 영향으로 분류된 특정 유형의 권한을 허용합니다.

  참고 항목

  위의 권장 사항은 가장 이상적인 보안 구성을 기반으로 제안됩니다. 그러나 보안은 기능과 작업 간의 미세한 균형을 맞추기 때문에 가장 안전한 구성으로 인해 관리자에게 더 많은 오버헤드가 발생할 수 있습니다. 관리자와 상의한 후 가장 적합한 결정입니다.

  위험 기반 단계별 동의 구성 - 권한 부여에 대한 사용자 동의를 사용하는 경우 기본적으로 사용하도록 설정됨

• 위험 기반 상향 동의는 불법 동의 요청을 보내는 악성 앱에 대한 사용자 노출을 줄이는 데 도움이 됩니다. Microsoft가 위험한 최종 사용자 동의 요청을 감지하는 경우 요청에는 관리자 동의에 대한 "단계별 단계"가 필요합니다. 이 기능은 기본적으로 사용하도록 설정되어 있지만 최종 사용자 동의를 사용하도록 설정한 경우에만 동작이 변경됩니다.

• 위험한 동의 요청이 감지되면 동의 프롬프트에 관리자 승인이 필요하다는 메시지가 표시됩니다. 관리자 동의 요청 워크플로를 사용하는 경우 사용자는 동의 프롬프트에서 직접 추가 검토를 위해 관리자에게 요청을 보낼 수 있습니다. 사용하도록 설정하면 다음 메시지가 표시됩니다.

  AADSTS90094: <clientAppDisplayName> 에는 관리자만 부여할 수 있는 조직의 리소스에 액세스할 수 있는 권한이 필요합니다. 사용하기 전에 이 앱에 대한 권한을 부여하도록 관리자에게 요청하세요. 이 경우 감사 이벤트는 "ApplicationManagement" 활동 유형 "애플리케이션에 동의"의 범주 및 "위험한 애플리케이션 검색됨"의 상태 이유와 함께 기록됩니다.

참고 항목

관리자의 승인이 필요한 모든 작업에는 작업 오버헤드가 있습니다. "동의 및 권한, 사용자 동의 설정"은 현재 미리 보기로 제공됩니다. GA(일반 공급)가 준비되면 "확인된 게시자의 사용자 동의 허용, 선택한 권한에 대한 사용자 동의 허용" 기능은 관리자의 오버헤드를 줄여야 하며 대부분의 조직에 권장됩니다.

애플리케이션 개발자에게 신뢰할 수 있는 앱 에코시스템을 따르도록 교육합니다. 개발자가 고품질의 안전한 통합을 빌드할 수 있도록 Microsoft Entra 앱 등록에서 Integration Assistant의 공개 미리 보기도 발표 합니다.

• Integration Assistant는 앱 등록을 분석하고 권장 보안 모범 사례 집합에 대해 벤치마킹합니다.
• Integration Assistant는 개발에서 모니터링에 이르기까지 통합 수명 주기의 각 단계에서 관련된 모범 사례를 강조 표시하고 모든 단계가 제대로 구성되도록 합니다.
• 첫 번째 앱을 통합하든, 기술을 향상하려는 전문가이든 관계없이 작업을 더 쉽게 수행할 수 있습니다.

조직에서 동의 전술(피싱 전술, 관리자 및 사용자 동의)을 교육합니다.

• 잘못된 맞춤법과 문법이 있는지 확인합니다. 전자 메일 메시지 또는 애플리케이션의 동의 화면에 맞춤법 및 문법 오류가 있는 경우 의심스러운 애플리케이션일 수 있습니다.
• 앱 이름 및 도메인 URL에 주의해야 합니다. 공격자는 합법적인 애플리케이션 또는 회사에서 온 것처럼 보이지만 악의적인 앱에 동의하도록 유도하는 앱 이름을 스푸핑하는 것을 좋아합니다.
• 애플리케이션에 동의하기 전에 앱 이름 및 도메인 URL을 인식해야 합니다.

신뢰할 수 있는 앱 홍보 및 액세스 허용

• 게시자가 확인된 애플리케이션의 사용을 승격합니다. 게시자 확인을 통해 관리자와 최종 사용자는 애플리케이션 개발자의 신뢰성을 파악할 수 있습니다. 지금까지 390개의 게시자가 660개 이상의 애플리케이션을 확인했습니다.
• 사용자가 조직 또는 확인된 게시자에서 개발한 애플리케이션과 같이 신뢰할 수 있는 특정 애플리케이션에만 동의할 수 있도록 하여 애플리케이션 동의 정책을 구성합니다.
• 사용 권한 및 동의 프레임워크의 작동 방식에 대해 조직에 교육합니다.
• 애플리케이션이 요구하는 데이터 및 사용 권한을 이해하고 플랫폼 내에서 사용 권한 및 동의가 작동하는 방식을 이해합니다.
• 관리자가 동의 요청을 관리하고 평가하는 방법을 알고 있는지 확인합니다.

조직에서 애플리케이션 및 동의한 권한을 감사하여 사용 중인 애플리케이션이 필요한 데이터에만 액세스하고 최소한의 권한 원칙을 준수하는지 확인합니다.

해결 방법

• 고객 교육 및 애플리케이션 동의 부여 보안에 대한 인식 및 교육 제공
• 조직 정책 및 기술 제어를 사용하여 애플리케이션 동의 부여 프로세스 강화
• 일정 만들기를 설정하여 동의된 애플리케이션 검토
• PowerShell을 사용하여 앱을 사용하지 않도록 설정하여 의심되거나 악의적인 앱을 사용하지 않도록 설정할 수 있습니다.

관련 콘텐츠

• 원격 인력 애플리케이션 공격 보호
• 안전하고 신뢰할 수 있는 앱 에코시스템 육성
• 위험 OAuth 앱 조사
• 애플리케이션에 대한 동의 관리 및 동의 요청 평가
• Microsoft Entra ID에서 엔터프라이즈 앱에 대한 사용자 로그인 사용 안 함
• Microsoft ID 플랫폼의 권한 및 동의 프레임워크를 이해합니다.
• 위임 권한 및 애플리케이션 권한 간의 차이점을 이해
• 최종 사용자가 애플리케이션에 동의하는 방법 구성
• 내 애플리케이션 목록에서 예기치 않은 애플리케이션
• 불법 동의 부여 검색 및 수정
• Microsoft Entra 애플리케이션이 추가되는 방법 및 이유
• Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체
• Microsoft Entra Config Documentor
• 애플리케이션에 대한 동의 관리 및 동의 요청 평가
• Get-AzureADServicePrincipal
• 빌드 2020: 모든 사용자를 위한 안전하고 신뢰할 수 있는 앱 에코시스템 육성
• 관리자 동의 워크플로 구성
• 관리자는 요청을 승인하기 전에 모든 동의 요청을 신중하게 평가해야 합니다.
• 애플리케이션 등록 및 엔터프라이즈 애플리케이션
• 권한
• AppConsent 피싱의 KrebsOnSecurity

추가 인시던트 응답 플레이북

다음과 같은 추가 유형의 공격을 식별하고 조사하기 위한 지침을 검토합니다.

• 피싱(Phishing)
• 암호 스프레이

인시던트 대응 리소스

• 새로운 역할 및 숙련된 분석가를 위한 Microsoft 보안 제품 및 리소스 개요
• SOC(보안 운영 센터) 계획
• Microsoft Defender XDR 인시던트 대응
• 클라우드용 Microsoft Defender(Azure)
• Microsoft Sentinel 인시던트 대응
• Microsoft 인시던트 대응 팀 가이드가 보안 팀 및 리더를 위한 모범 사례를 공유합니다.
• Microsoft 인시던트 대응 가이드는 보안 팀이 의심스러운 활동을 분석하는 데 도움이 됩니다.