손상된 애플리케이션 및 악의적인 애플리케이션 조사
이 문서에서는 고객 테넌트에서 하나 이상의 애플리케이션에 대한 악의적인 공격을 식별하고 조사하는 지침을 제공합니다. 단계별 지침은 정보를 보호하고 추가 위험을 최소화하는 데 필요한 수정 작업을 수행하는 데 도움이 됩니다.
- 필수 구성 요소: 조사를 시작하기 전에 완료해야 하는 특정 요구 사항을 다룹니다. 예를 들어 설정해야 하는 로깅, 역할 및 사용 권한이 필요합니다.
- 워크플로: 이 조사를 수행하기 위해 따라야 하는 논리적 흐름을 표시합니다.
- 조사 단계: 이 특정 조사에 대한 자세한 단계별 지침을 포함합니다.
- 포함 단계: 손상된 애플리케이션을 사용하지 않도록 설정하는 방법에 대한 단계를 포함합니다.
- 복구 단계: 손상된 애플리케이션에 대한 악의적인 공격을 복구/완화하는 방법에 대한 개략적인 단계를 포함합니다.
- 참조: 다른 읽기 및 참조 자료를 포함합니다.
필수 조건
조사를 시작하기 전에 자세한 정보를 수집할 수 있는 올바른 도구와 권한이 있는지 확인합니다.
ID 보호 신호를 사용하려면 테넌트에 Microsoft Entra ID P2에 대한 라이선스가 있어야 합니다.
다음 디렉터리 역할이 있는 계정:
- 글로벌 관리자
- 보안 관리자
Microsoft Graph 탐색기를 사용하고 Microsoft Graph API에 어느 정도 익숙해질 수 있습니다.
테넌트 내의 모든 엔터프라이즈 앱에 책임의 목적으로 설정된 소유자가 있는지 확인합니다. 앱 소유자 개요 및 앱 소유자 할당에 대한 개념을 검토합니다.
앱 동의 허용 조사(일부https://aka.ms/IRPlaybooks)의 개념을 숙지합니다.
다음 Microsoft Entra 권한을 이해해야 합니다.
워크로드 ID 위험 검색의 개념을 숙지합니다.
클라우드용 Microsoft Defender 앱을 사용하려면 전체 Microsoft 365 E5 라이선스가 있어야 합니다.
- 변칙 검색 경고 조사의 개념 이해
다음 애플리케이션 관리 정책을 숙지합니다.
다음 앱 거버넌스 정책을 숙지합니다.
필요한 도구
효과적인 조사를 위해 조사 컴퓨터에 다음 PowerShell 모듈 및 도구 키트를 설치합니다.
워크플로
조사 단계
이 조사의 경우 사용자 보고서, Microsoft Entra 로그인 로그 예제 또는 ID 보호 검색 형식의 잠재적인 애플리케이션 손상에 대한 표시가 있다고 가정합니다. 필요한 모든 필수 구성 요소 단계를 완료하고 사용하도록 설정해야 합니다.
이 플레이북은 모든 Microsoft 고객 및 조사 팀이 전체 Microsoft 365 E5 또는 Microsoft Entra ID P2 라이선스 제품군을 사용하거나 구성하지 않도록 하여 만들어집니다. 이 플레이북은 적절한 경우 다른 자동화 기능을 강조 표시합니다.
애플리케이션 유형 확인
애플리케이션 소유자에게 연락하는 데 필요한 올바른 정보를 얻으려면 조사 단계 초기에 애플리케이션 유형(다중 또는 단일 테넌트)을 확인하는 것이 중요합니다. 자세한 내용은 Microsoft Entra ID의 테넌트를 참조하세요.
다중 테넌트 애플리케이션
다중 테넌트 애플리케이션의 경우 애플리케이션은 제3자가 호스팅하고 관리합니다. 애플리케이션 소유자에게 연락하여 문제를 보고하는 데 필요한 프로세스를 식별합니다.
단일 테넌트 애플리케이션
조직 내에서 애플리케이션 소유자의 연락처 세부 정보를 찾습니다. 엔터프라이즈 애플리케이션 섹션의 소유자 탭 에서 찾을 수 있습니다 . 또는 조직에 이 정보가 있는 데이터베이스가 있을 수 있습니다.
이 Microsoft Graph 쿼리를 실행할 수도 있습니다.
GET https://graph.microsoft.com/v1.0/applications/{id}/owners
ID 보호 확인 - 위험한 워크로드 ID
이 기능은 이 플레이북을 작성할 때 미리 보기로 제공되며 사용량에 라이선스 요구 사항이 적용됩니다. 위험한 워크로드 ID는 서비스 주체를 조사하는 트리거일 수 있지만 식별한 다른 트리거를 자세히 조사하는 데도 사용할 수 있습니다. ID 보호 - 위험한 워크로드 ID 탭을 사용하여 서비스 주체의 위험 상태를 검사 또는 Microsoft Graph API를 사용할 수 있습니다.
비정상적인 로그인 동작 확인
조사의 첫 번째 단계는 서비스 주체 사용에서 비정상적인 인증 패턴의 증거를 찾는 것입니다. Azure Portal, Azure Monitor, Microsoft Sentinel 또는 조직에서 선택한 SIEM(보안 정보 및 이벤트 관리) 시스템 내에서 서비스 주체 로그인 섹션에서 다음 을 찾습니다 .
- 위치 - 서비스 주체가 예상하지 못한 위치\IP 주소에서 인증하고 있나요?
- 실패 - '서비스 주체에 대한 인증 실패가 많나요?
- 타임스탬프 - 예상하지 못한 시간에 발생하는 성공적인 인증이 있나요?
- 빈도 - 서비스 주체에 대한 인증 빈도가 증가합니까?
- 자격 증명 누수 - 애플리케이션 자격 증명이 GitHub와 같은 공용 원본에 하드 코딩되고 게시되었나요?
Entra ID ID 보호 - 위험한 워크로드 ID를 배포한 경우 의심스러운 로그인 및 자격 증명 누출 검색을 검사. 자세한 내용은 워크로드 ID 위험 구금을 참조 하세요.
대상 리소스 확인
서비스 주체 로그인 내에서도 인증 중에 서비스 주체가 액세스하고 있던 리소스를 검사. 서비스 주체가 액세스해야 하는 리소스에 익숙하기 때문에 애플리케이션 소유자로부터 입력을 받는 것이 중요합니다.
비정상적인 자격 증명 변경 확인
감사 로그를 사용하여 애플리케이션 및 서비스 주체의 자격 증명 변경에 대한 정보를 가져옵니다. 애플리케이션 관리별 범주 및 업데이트 애플리케이션별 작업 ( 인증서 및 비밀 관리)을 필터링합니다.
- 서비스 주체에 새로 만든 자격 증명 또는 예기치 않은 자격 증명이 할당되었는지 확인합니다.
- Microsoft Graph API를 사용하여 서비스 주체에서 자격 증명을 확인합니다.
- 애플리케이션 및 연결된 서비스 주체 개체를 모두 확인합니다.
- 만들거나 수정한 사용자 지정 역할을 확인합니다. 아래에 표시된 사용 권한을 확인합니다.
클라우드용 Microsoft Defender Apps에서 앱 거버넌스를 배포한 경우 애플리케이션과 관련된 경고를 위해 Azure Portal을 검사. 자세한 내용은 앱 위협 감지 및 수정 시작을 참조 하세요.
ID 보호를 배포한 경우 "위험 검색" 보고서와 사용자 또는 워크로드 ID "위험 기록"을 검사.
클라우드용 Microsoft Defender 앱을 배포한 경우 "OAuth 앱에 자격 증명의 비정상적인 추가" 정책이 사용하도록 설정되어 있는지 확인하고 열려 있는 경고에 대해 검사.
자세한 내용은 OAuth 앱에 비정상적인 자격 증명 추가를 참조 하세요.
또한 servicePrincipalRiskDetections 및 user riskDetections API를 쿼리하여 이러한 위험 검색을 검색할 수 있습니다.
비정상적인 앱 구성 변경 내용 검색
- 앱에 할당된 API 권한을 확인하여 사용 권한이 앱에 대해 예상되는 것과 일치하는지 확인합니다.
- 감사 로그(애플리케이션 업데이트 또는 업데이트 서비스 주체별 필터 작업)를 확인합니다.
- 연결 문자열 일관성이 있는지 여부와 로그아웃 URL이 수정되었는지 확인합니다.
- URL의 do기본가 등록된 것과 인라인인지 확인합니다.
- 권한이 없는 리디렉션 URL을 추가한 사람이 있는지 여부를 확인합니다.
- 사용자가 소유한 리디렉션 URI의 소유권을 확인하여 만료되지 않았고 악의적 사용자가 클레임했는지 확인합니다.
또한 클라우드용 Microsoft Defender 앱을 배포한 경우 현재 조사 중인 애플리케이션과 관련된 경고를 Azure Portal에 검사. OAuth 앱에 대해 기본적으로 모든 경고 정책이 사용하도록 설정되는 것은 아니므로 이러한 정책이 모두 사용하도록 설정되어 있는지 확인합니다. 자세한 내용은 OAuth 앱 정책을 참조 하세요. 조사>OAuth 앱 탭에서 앱 보급 및 최근 활동에 대한 정보를 볼 수도 있습니다.
의심스러운 애플리케이션 역할 확인
- 감사 로그를 사용할 수도 있습니다. 서비스 주체에 앱 역할 할당을 추가하여 작업을 필터링합니다.
- 할당된 역할에 높은 권한이 있는지 확인합니다.
- 이러한 권한이 필요한지 확인합니다.
확인되지 않은 상용 앱 확인
- 상업용 갤러리(게시된 버전 및 확인된 버전) 애플리케이션이 사용되고 있는지 확인합니다.
keyCredential 속성 정보 공개의 표시 확인
CVE-2021-42306에 설명된 대로 잠재적인 keyCredential 속성 정보 공개에 대한 테넌트를 검토합니다.
영향을 받은 Automation 실행 계정과 연결된 영향을 받은 Microsoft Entra 애플리케이션을 식별하고 수정하려면 수정 지침 GitHub 리포지토리로 이동하세요.
Important
손상 증거: 손상 증거를 발견한 경우 포함 및 복구 섹션에서 강조 표시된 단계를 수행하는 것이 중요합니다. 이러한 단계는 위험을 해결하는 데 도움이 되지만 추가 영향을 방지하고 잘못된 행위자가 제거되도록 손상 원인을 파악하기 위해 추가 조사를 수행합니다.
애플리케이션을 사용하여 시스템에 액세스하는 두 가지 기본 방법이 있습니다. 첫 번째는 일반적으로 피싱 공격을 통해 관리자 또는 사용자가 동의한 애플리케이션을 포함합니다. 이 메서드는 시스템에 대한 초기 액세스의 일부이며 종종 "동의 피싱"이라고 합니다.
두 번째 방법은 지속성, 데이터 수집 및 레이더를 유지하기 위해 새 앱을 만드는 이미 손상된 관리자 계정을 포함합니다. 예를 들어 손상된 관리자는 겉보기에 무해한 이름으로 OAuth 앱을 만들 수 있으므로 검색을 방지하고 계정 없이도 데이터에 장기적으로 액세스할 수 있습니다. 이 방법은 종종 국가 공격에서 볼 수 있습니다.
다음은 추가 조사를 위해 수행할 수 있는 몇 가지 단계입니다.
지난 7일 동안의 피싱 표시는 Microsoft 365 UAL(통합 감사 로그)을 확인하세요.
때로는 공격자가 악의적이거나 손상된 애플리케이션을 지속성 수단으로 사용하거나 데이터를 유출하는 경우 피싱 캠페인이 포함됩니다. 이전 단계의 결과에 따라 다음의 ID를 검토해야 합니다.
- 애플리케이션 소유자
- 동의 관리
지난 24시간 동안 피싱 공격의 징후에 대한 ID를 검토합니다. 즉각적인 징후가 없는 경우 필요한 경우 이 시간 범위를 7, 14 및 30일로 늘림 자세한 피싱 조사 플레이북은 피싱 조사 플레이북을 참조 하세요.
지난 7일 동안의 악의적인 애플리케이션 동의 검색
테넌트에 추가된 애플리케이션을 가져오기 위해 공격자는 사용자 또는 관리자를 스푸핑하여 애플리케이션에 동의합니다. 공격의 징후에 대한 자세한 내용은 애플리케이션 동의 부여 조사 플레이북을 참조 하세요.
플래그가 지정된 애플리케이션에 대한 애플리케이션 동의 확인
감사 로그 확인
해당 애플리케이션에 대한 모든 동의 부여를 보려면 애플리케이션에 대한 동의로 활동을 필터링합니다.
Microsoft Entra 관리 센터 감사 로그 사용
Microsoft Graph를 사용하여 감사 로그 쿼리
a) 특정 시간 프레임에 대한 필터:
GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24
b) '애플리케이션에 동의' 감사 로그 항목에 대한 감사 로그를 필터링합니다.
https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
{
"id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
"category": "ApplicationManagement",
"correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
"result": "success",
"resultReason": "",
"activityDisplayName": "Consent to application",
"activityDateTime": "2022-03-25T21:21:37.9452149Z",
"loggedByService": "Core Directory",
"operationType": "Assign",
"initiatedBy": {
"app": null,
"user": {
"id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
"displayName": null,
"userPrincipalName": "admin@contoso.com",
"ipAddress": "55.154.250.91",
"userType": null,
"homeTenantId": null,
"homeTenantName": null
}
},
"targetResources": [
{
"id": "d23d38a1-02ae-409d-884c-60b03cadc989",
"displayName": "Graph explorer (official site)",
"type": "ServicePrincipal",
"userPrincipalName": null,
"groupType": null,
"modifiedProperties": [
{
"displayName": "ConsentContext.IsAdminConsent",
"oldValue": null,
"newValue": "\"True\""
},
c) Log Analytics 사용
AuditLogs
| where ActivityDisplayName == "Consent to application"
자세한 내용은 애플리케이션 동의 부여 조사 플레이북을 참조 하세요.
애플리케이션에 대한 의심스러운 최종 사용자 동의가 있는지 확인
사용자는 해당 사용자 역할을 수행하는 동안 보호된 리소스의 일부 데이터에 액세스할 수 있는 권한을 애플리케이션에 부여할 수 있습니다. 이러한 유형의 액세스를 허용하는 사용 권한을 "위임된 권한" 또는 사용자 동의라고 합니다.
사용자가 동의한 앱을 찾으려면 LogAnalytics를 사용하여 감사 로그를 검색합니다.
AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")
감사 로그를 확인하여 부여된 권한이 너무 광범위한지 확인합니다(테넌트 전체 또는 관리자 동의).
애플리케이션 또는 서비스 주체에 부여된 사용 권한을 검토하는 작업은 시간이 오래 걸릴 수 있습니다. Microsoft Entra ID에서 잠재적으로 위험한 사용 권한을 이해하는 것부터 시작합니다 .
이제 앱 동의 부여 조사에서 사용 권한을 열거하고 검토하는 방법에 대한 지침을 따릅니다.
이 작업을 수행할 수 없는 사용자 ID에 의해 사용 권한이 부여되었는지 여부 또는 이상한 날짜 및 시간에 작업이 수행되었는지 확인합니다.
감사 로그를 사용하여 검토합니다.
AuditLogs
| where OperationName == "Consent to application"
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"
Microsoft Entra 감사 로그를 사용하여 애플리케이션에 대한 동의를 기준으로 필터링할 수도 있습니다. 감사 로그 세부 정보 섹션에서 수정된 속성을 클릭한 다음 ConsentAction.Permissions를 검토합니다.
포함 단계
하나 이상의 애플리케이션 또는 워크로드 ID를 악의적이거나 손상된 것으로 식별한 후에는 이 애플리케이션에 대한 자격 증명을 즉시 배포하지 않고 애플리케이션을 즉시 삭제하려고 할 수도 있습니다.
Important
다음 단계를 수행하기 전에 조직은 애플리케이션을 사용하지 않도록 설정하면 보안 영향 및 비즈니스 영향을 고려해야 합니다. 애플리케이션을 사용하지 않도록 설정하면 비즈니스에 미치는 영향이 너무 큰 경우 이 프로세스의 복구 단계를 준비하고 이동하는 것이 좋습니다.
손상된 애플리케이션 사용 안 함
일반적인 포함 전략에는 식별된 애플리케이션에 대한 로그인을 사용하지 않도록 설정하여 인시던트 대응 팀 또는 영향을 받는 사업부에 삭제 또는 키 롤링의 영향을 평가할 시간을 제공하는 것이 포함됩니다. 조사를 통해 관리자 계정 자격 증명도 손상되었다고 생각되는 경우 테넌트에 액세스하는 모든 경로가 동시에 차단되도록 이 유형의 활동을 제거 이벤트와 조정해야 합니다.
다음 Microsoft Graph PowerShell 코드를 사용하여 앱에 대한 로그인을 사용하지 않도록 설정할 수도 있습니다.
# The AppId of the app to be disabled
$appId = "{AppId}"
# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
# Service principal exists already, disable it
$ServicePrincipalUpdate =@{
"accountEnabled" = "false"
}
Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
} else {
# Service principal does not yet exist, create it and disable it at the same time
$ServicePrincipalID=@{
"AppId" = $appId
"accountEnabled" = "false"
}
$servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
}
복구 단계
서비스 주체 수정
위험한 서비스 주체에 할당된 모든 자격 증명을 나열합니다. 이 작업을 수행하는 가장 좋은 방법은 GET ~/application/{id}를 사용하여 Microsoft Graph 호출을 수행하는 것입니다. 여기서 전달된 ID는 애플리케이션 개체 ID입니다.
자격 증명에 대한 출력을 구문 분석합니다. 출력에는 passwordCredentials 또는 keyCredentials가 포함될 수 있습니다. 모두에 대한 keyId를 기록합니다.
"keyCredentials": [], "parentalControlSettings": { "countriesBlockedForMinors": [], "legalAgeGroupRule": "Allow" }, "passwordCredentials": [ { "customKeyIdentifier": null, "displayName": "Test", "endDateTime": "2021-12-16T19:19:36.997Z", "hint": "7~-", "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef", "secretText": null, "startDateTime": "2021-06-16T18:19:36.997Z" } ],
애플리케이션 addKey API를 사용하여 애플리케이션 개체에 새(x509) 인증서 자격 증명을 추가합니다.
POST ~/applications/{id}/addKey모든 이전 자격 증명을 즉시 제거합니다. 이전 암호 자격 증명 각각에 대해 다음을 사용하여 제거합니다.
POST ~/applications/{id}/removePassword각 이전 키 자격 증명에 대해 다음을 사용하여 제거합니다.
POST ~/applications/{id}/removeKey애플리케이션과 연결된 모든 서비스 주체를 수정합니다. 테넌트가 다중 테넌트 애플리케이션을 호스트/등록하고 애플리케이션에 연결된 여러 서비스 주체를 등록하는 경우 이 단계를 수행합니다. 이전에 나열된 것과 비슷한 단계를 수행합니다.
GET ~/servicePrincipals/{id}
응답에서 passwordCredentials 및 keyCredentials 찾기, 모든 이전 keyId 기록
모든 이전 암호 및 키 자격 증명을 제거합니다. 올바른 사용:
POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.
영향을 받는 서비스 주체 리소스 수정
다음 우선 순위에서 서비스 주체를 순환하여 액세스 권한이 있는 KeyVault 비밀을 수정합니다.
- GetSecret 호출로 직접 노출되는 비밀입니다.
- 노출된 KeyVaults의 나머지 비밀입니다.
- 노출된 구독의 나머지 비밀입니다.
자세한 내용은 서비스 주체 또는 애플리케이션의 인증서 및 비밀을 대화형으로 제거하고 롤오버하는 것을 참조 하세요.
애플리케이션에 대한 Microsoft Entra SecOps 지침은 애플리케이션에 대한 Microsoft Entra 보안 작업 가이드를 참조 하세요.
우선 순위에 따라 이 시나리오는 다음과 같습니다.
- 자격 증명 롤오버에 대한 예제를 포함하도록 Graph PowerShell cmdlet(ApplicationKey + ApplicationPassword 추가/제거) 문서를 업데이트합니다.
- 이 시나리오를 간소화하는 사용자 지정 cmdlet을 Microsoft Graph PowerShell에 추가합니다.
악의적인 애플리케이션 사용 안 함 또는 삭제
애플리케이션을 사용하지 않도록 설정하거나 삭제할 수 있습니다. 애플리케이션을 사용하지 않도록 설정하려면 사용자가 로그인할 수 있도록 설정에서 토글을 아니요로 이동합니다.
Azure Portal 또는 Microsoft Graph API를 통해 일시적으로 또는 영구적으로 애플리케이션을 삭제할 수 있습니다. 일시 삭제하면 삭제 후 최대 30일 후에 애플리케이션을 복구할 수 있습니다.
DELETE /applications/{id}
애플리케이션을 영구적으로 삭제하려면 다음 Microsoft Graph API 호출을 사용합니다.
DELETE /directory/deletedItems/{id}
애플리케이션을 사용하지 않도록 설정하거나 애플리케이션을 일시 삭제하는 경우 Microsoft Entra 감사 로그에서 모니터링을 설정하여 상태가 다시 활성화 또는 복구로 변경되는지 알아봅니다.
사용하도록 설정에 대한 로깅:
- 서비스 - 핵심 디렉터리
- 활동 유형 - 서비스 주체 업데이트
- 범주 - 애플리케이션 관리
- (행위자) - 행위자의 UPN에 의해 시작됨
- 대상 - 앱 ID 및 표시 이름
- 수정된 속성 - 속성 이름 = 계정 사용, 새 값 = true
복구에 대한 로깅:
- 서비스 - 핵심 디렉터리
- 활동 유형 - 서비스 주체 추가
- 범주 - 애플리케이션 관리
- (행위자) - 행위자의 UPN에 의해 시작됨
- 대상 - 앱 ID 및 표시 이름
- 수정된 속성 - 속성 이름 = 계정 사용, 새 값 = true
참고: Microsoft는 서비스 약관을 위반하는 것으로 확인된 애플리케이션을 전역적으로 사용하지 않도록 설정합니다. 이러한 경우 이러한 애플리케이션은 Microsoft Graph의 관련 애플리케이션 및 서비스 주체 리소스 유형의 속성에 표시됩니다DisabledDueToViolationOfServicesAgreement.disabledByMicrosoftStatus 나중에 조직에서 다시 인스턴스화되지 않도록 하기 위해 이러한 개체를 삭제할 수 없습니다.
워크로드 ID에 대한 ID 보호 구현
Microsoft는 로그인 동작 및 오프라인 손상 지표에서 워크로드 ID에 대한 위험을 감지합니다.
자세한 내용은 ID 보호를 사용하여 워크로드 ID 보안을 참조하세요.
이러한 경고는 ID 보호 포털에 표시되며 진단 설정 또는 ID 보호 API를 통해 SIEM 도구로 내보낼 수 있습니다.
위험한 워크로드 ID에 대한 조건부 액세스
조건부 액세스를 사용하면 ID 보호에서 "위험"으로 표시할 때 지정하는 특정 계정에 대한 액세스를 차단할 수 있습니다. 조건부 액세스를 통한 적용은 현재 단일 테넌트 애플리케이션으로만 제한됩니다.
자세한 내용은 워크로드 ID에 대한 조건부 액세스를 참조 하세요.
애플리케이션 위험 정책 구현
사용자 동의 설정 검토
Microsoft Entra ID>Enterprise 애플리케이션>동의 및 사용 권한 사용자 동의 설정에서 사용자 동의 설정을 검토합니다.>
구성 옵션을 검토하려면 사용자가 앱에 동의하는 방법 구성을 참조 하세요.
관리자 동의 흐름 구현
애플리케이션 개발자가 전체 테넌트에 대한 동의를 제공하려는 의도로 사용자를 관리자 동의 엔드포인트로 안내하는 경우 이를 관리자 동의 흐름이라고 합니다. 관리자 동의 흐름이 제대로 작동되도록 하려면 애플리케이션 개발자는 애플리케이션 매니페스트의 RequiredResourceAccess 속성에서 모든 사용 권한을 나열해야 합니다.
대부분의 조직에서는 사용자가 애플리케이션에 동의할 수 있는 기능을 사용하지 않도록 설정합니다. 사용자에게 애플리케이션에 대한 동의를 계속 요청하고 관리 검토 기능을 가질 수 있는 기능을 제공하려면 관리자 동의 워크플로를 구현하는 것이 좋습니다. 관리자 동의 워크플로 단계에 따라 테넌트에서 구성합니다.
관리자 동의와 같은 높은 권한 있는 작업의 경우 지침에 정의된 권한 있는 액세스 전략을 갖습니다.
위험 기반 단계별 동의 설정 검토
위험 기반 단계별 동의는 악의적인 앱에 대한 사용자 노출을 줄이는 데 도움이 됩니다. 예를 들어 게시자가 확인되지 않고 기본이 아닌 권한이 필요한 새로 등록된 다중 테넌트 앱에 대한 동의 요청은 위험한 것으로 간주됩니다. 위험 사용자 동의 요청이 감지되면 요청에 관리자 동의에 대한 "스텝업"이 대신 필요합니다. 이 스텝업 기능은 기본적으로 사용하도록 설정되어 있지만 사용자 동의가 사용하도록 설정된 경우에만 동작이 변경됩니다.
테넌트에서 사용하도록 설정되어 있는지 확인하고 여기에 설명된 구성 설정을 검토합니다.
참조
- 인시던트 응답 플레이북
- 앱 동의 권한 부여
- Microsoft Entra ID Protection 위험
- Microsoft Entra 보안 모니터링 가이드
- 애플리케이션 감사 개념
- 사용자가 애플리케이션에 동의하는 방법 구성
- 관리자 동의 워크플로 구성
- OAuth 앱에 비정상적인 자격 증명 추가
- ID 보호를 사용하여 워크로드 ID 보호
- Microsoft의 전체적인 손상된 ID 신호
추가 인시던트 응답 플레이북
다음과 같은 추가 유형의 공격을 식별하고 조사하기 위한 지침을 검토합니다.
인시던트 대응 리소스
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기