Android용 Intune 앱 SDK - 다중 ID

Android용 Microsoft Intune 앱 SDK를 사용하면 Intune 앱 보호 정책(MAM 정책이라고도 함)을 네이티브 Java/Kotlin Android 앱에 통합할 수 있습니다. Intune 관리 애플리케이션은 Intune 앱 SDK와 통합된 애플리케이션입니다. Intune 관리자는 Intune에서 앱을 적극적으로 관리할 때 Intune 관리 앱에 앱 보호 정책을 쉽게 배포할 수 있습니다.

참고

이 가이드는 여러 단계로 나뉩니다. 먼저 1단계: 통합 계획을 검토합니다.

5단계: 다중 ID

스테이지 목표

애플리케이션에 다중 ID 지원이 필요한지 확인합니다.
Intune 앱 SDK가 ID를 인식하는 방법을 이해합니다.
ID 인식을 위해 애플리케이션을 리팩터링합니다.
애플리케이션 전체에서 활성 및 변경되는 ID를 SDK에 알리는 코드를 추가합니다.
관리 ID와 관리되지 않는 ID 모두에 대해 앱 보호 정책 적용을 철저히 테스트합니다.

ID 용어

"사용자", "계정" 및 "ID"라는 용어는 종종 같은 의미로 사용됩니다. 이 가이드에서는 다음과 같이 구분하려고 시도합니다.

사용자: 소프트웨어 제품을 사용하는 사람입니다. 또한 최종 사용자, Android 앱을 사용하는 사람, 관리자 / 관리자 사용자 / IT 관리자 / IT 전문가, Microsoft Intune 관리 센터를 사용하는 사람으로 구분됩니다.
계정: 사용자의 엔터티를 고유하게 식별하는 organization에 속한 소프트웨어 레코드입니다. 인간 사용자는 여러 계정을 가질 수 있습니다.
ID: Intune 앱 SDK에서 계정을 고유하게 식별하는 데 사용하는 데이터 집합입니다.

배경

기본적으로 Intune 앱 SDK는 전체 애플리케이션에 정책을 적용합니다. 대상 앱 보호 정책에 계정을 등록하면 SDK는 모든 파일 및 모든 활동을 해당 계정의 ID와 연결하고 해당 계정의 대상 정책을 보편적으로 적용합니다.

많은 개발자에게 이는 응용 프로그램에 바람직한 앱 보호 동작입니다. 이러한 애플리케이션은 단일 ID로 간주됩니다. 이전 단계를 완료하면 애플리케이션이 단일 ID로 성공적으로 통합되고 모든 기본 정책을 적용할 수 있습니다. 단일 ID를 유지하려는 앱은 이 섹션을 건너뛰고 6단계: App Configuration으로 진행할 수 있습니다.

Intune 앱 SDK는 필요에 따라 ID별 수준에서 정책을 적용할 수 있습니다. 응용 프로그램이 이미 동시에 로그인한 여러 계정을 지원하고 있고 앱 보호 정책으로 이 다중 계정 지원을 유지하려는 경우 응용 프로그램은 다중 ID로 간주됩니다.

팁

애플리케이션이 단일 ID 또는 다중 ID 보호를 지원해야 하는지 확실하지 않은 경우 내 애플리케이션이 단일 ID입니까, 아니면 다중 ID입니까?

경고

다중 ID를 지원하는 것은 다른 앱 보호 기능보다 훨씬 더 복잡합니다. 다중 ID를 부적절하게 통합하면 데이터 유출 및 기타 보안 문제가 발생할 수 있습니다. 이 섹션을 주의 깊게 검토하고 다음 단계로 진행하기 전에 충분한 테스트 시간을 계획합니다.

SDK에 대한 "ID"

SDK 통합 애플리케이션이 registerAccountForMAM을 사용하여 계정을 등록하면 SDK는 제공된 모든 매개 변수(upn, aadId, tenantId 및 권한)를 ID로 저장합니다. 그러나 대부분의 SDK ID API는 제공된 OID(Microsoft Entra ID 또는 AAD ID라고도 함)를 ID의 식별자로 사용합니다. MAM SDK API는 OID 문자열을 ID로 반환하며 ID에 OID 문자열 매개 변수가 필요합니다. 일부 메서드는 UPN 문자열을 가져오거나 반환할 수도 있으며, 이 경우 UPN은 정보 제공용으로만 사용됩니다.

ID 매개 변수는 대/소문자를 구분하지 않습니다. ID에 대한 SDK의 요청은 ID를 등록하거나 설정할 때 사용된 것과 동일한 대/소문자를 반환하지 않을 수 있습니다.

주의

UPN 문자열을 가져오거나 반환하는 사용되지 않는 메서드를 사용하는 앱의 경우 앱은 다양한 API 호출에 전달되는 ID UPN 문자열이 일관되는지 확인해야 합니다. 일관성 없는 UPN 문자열을 전달하면 데이터 누수가 발생할 수 있습니다.

관리형 ID와 관리되지 않는 ID 비교

앱 보호 정책 등록에 설명된 대로 애플리케이션은 사용자가 로그인할 때 SDK에 알려야 합니다. 로그인 시점에 사용자의 계정은 앱 보호 정책의 대상이 될 수도 있고 대상이 아닐 수도 있습니다. 계정이 앱 보호 정책의 대상인 경우 SDK는 계정을 관리되는 것으로 간주합니다. 그렇지 않으면 관리되지 않습니다.

SDK는 관리되는 것으로 간주하는 ID에 대한 정책을 적용합니다. SDK는 관리되지 않는 것으로 간주하는 ID에 대한 정책을 적용하지 않습니다.

현재 Intune 앱 SDK는 디바이스당 단일 관리 ID만 지원합니다. SDK 통합 애플리케이션이 관리 ID를 등록하는 즉시 이후에 등록된 모든 ID는 현재 앱 보호 정책의 대상으로 지정되어 있더라도 관리되지 않는 것으로 처리됩니다.

관리 ID가 이미 장치에 등록되어 있고 앱이 앱 보호 정책을 대상으로 하는 다른 ID를 등록하는 경우 SDK는 MAMEnrollmentManager.Result.WRONG_USER 최종 사용자에게 수정 옵션을 반환하고 메시지를 표시합니다. 자세한 내용은 SDK의 알림 등록을 참조하세요.

참고

등록 시 앱 보호 정책의 대상이 되지 않은 계정은 관리되지 않는 계정으로 간주됩니다. 계정이 앱 보호 정책에 대한 라이선스가 없거나 대상 지정되지 않은 경우에도 SDK는 나중에 이 계정이 라이선스가 부여되고 대상이 되는지 정기적으로 검사합니다. 다른 관리 ID가 등록되지 않은 경우 SDK는 정책 대상이 되면 이 ID를 관리되는 ID로 처리하기 시작합니다. 사용자는 이 변경을 위해 로그아웃했다가 이 계정에 다시 로그인할 필요가 없습니다.

활성 ID

애플리케이션은 항상 SDK에 현재 사용 중인 ID(활성 ID라고도 함)를 알려야 합니다. 활성 ID가 관리되는 경우 SDK는 보호를 적용합니다. 활성 ID가 관리되지 않는 경우 SDK는 보호를 적용하지 않습니다.

SDK에는 애플리케이션별 지식이 없으므로 애플리케이션이 올바른 활성 ID를 공유하도록 신뢰해야 합니다.

애플리케이션에서 관리 ID가 실제로 사용 중일 때 관리되지 않는 ID가 활성 상태임을 SDK에 잘못 알리는 경우 SDK는 보호를 적용하지 않습니다. 이로 인해 데이터 유출이 발생하여 사용자의 데이터가 위험에 처할 수 있습니다.
애플리케이션에서 관리되지 않는 ID가 실제로 사용 중일 때 관리 ID가 활성 상태라고 SDK에 잘못 알리면 SDK가 보호를 부적절하게 적용합니다. 이것은 데이터 유출이 아니지만 이로 인해 관리되지 않는 사용자를 불필요하게 제한하고 관리되지 않는 사용자의 데이터가 삭제 위험에 노출될 수 있습니다.

애플리케이션에서 사용자의 데이터를 표시하는 경우 활성 ID에 속하는 데이터만 표시해야 합니다. 애플리케이션이 표시되는 데이터를 소유하는 사람을 현재 인식하지 못하는 경우 다중 ID 지원 통합을 시작하기 전에 ID 인식을 향상하도록 애플리케이션을 리팩터링해야 할 수 있습니다.

ID별로 앱 데이터 구성

애플리케이션이 새 파일을 작성할 때마다 SDK는 현재 활성 스레드 및 프로세스 ID를 기반으로 해당 파일과 ID를 연결("태그"라고도 함)합니다. 또는 앱에서 SDK를 직접 호출하여 특정 ID로 파일에 수동으로 태그를 지정할 수 있습니다(자세한 내용은 보호된 Files 쓰기 참조). SDK는 파일 암호화와 선택적 초기화 모두에 이 태그가 지정된 파일 ID를 사용합니다.

관리 ID가 암호화 정책의 대상인 경우 관리 ID로 태그가 지정된 파일만 암호화됩니다.

관리자 작업 또는 구성된 정책에서 관리 데이터를 삭제하도록 요청하면 관리 ID로 태그가 지정된 파일만 삭제됩니다.

SDK는 여러 ID를 단일 파일에 연결할 수 없습니다. 앱이 여러 사용자에 속한 데이터를 동일한 파일에 저장하는 경우 SDK의 기본 동작으로 인해 이 데이터가 과소 보호 또는 과도하게 보호됩니다. ID별로 앱의 데이터를 구성하는 것이 좋습니다.

앱이 동일한 파일에 다른 ID에 속하는 데이터를 반드시 저장해야 하는 경우 SDK는 파일 내 데이터의 하위 집합에 ID 태그를 지정하기 위한 기능을 제공합니다. 자세한 내용은 데이터 버퍼 보호 를 참조하세요.

다중 ID 구현

앱에 대한 다중 ID 지원을 선언하려면 먼저 다음 메타데이터를 AndroidManifest.xml에 배치합니다.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

활성 ID 설정

애플리케이션은 활성 ID를 다음 수준의 내림차순으로 설정할 수 있습니다.

스레드 수준
Context (일반적으로 Activity) 수준
프로세스 수준

스레드 수준에서 설정된 ID는 수준의 ID를 대체 Context 하며, 이는 프로세스 수준에서 설정된 ID를 대체합니다.

에 Context 설정된 ID는 적절한 관련 시나리오에서만 사용됩니다. 예를 들어 파일 IO 작업에는 연결된 Context. 가장 일반적으로 앱은 ContextActivity. 에서 IDActivity.onCreate를 Context 설정하는 것이 좋습니다. ID가 동일한 ID로 설정되지 않는 한 Activity 앱은 ID에 대한 데이터를 표시해서는 안 됩니다.

일반적으로 프로세스 수준 ID는 앱이 모든 스레드에서 한 번에 단일 ID로만 작동하는 경우에만 유용합니다. 이는 여러 계정을 지원하는 앱의 일반적인 동작이 아닙니다. 계정 데이터를 분리하고 스레드 또는 Context 수준에서 활성 ID를 설정하는 것이 좋습니다.

앱이 컨텍스트를 Application 사용하여 시스템 서비스를 획득하는 경우 스레드 또는 프로세스 ID가 설정되었거나 앱의 Application 컨텍스트에 UI ID를 설정했는지 확인합니다.

앱에서 컨텍스트를 Service 사용하여 의도를 시작하거나, 콘텐츠 확인자를 사용하거나, 다른 시스템 서비스를 활용하는 경우 컨텍스트에 ID Service 를 설정해야 합니다. 마찬가지로 앱에서 컨텍스트를 JobService 사용하여 이러한 작업을 수행하는 경우 구현에서 JobService 요구하는 대로 컨텍스트 또는 스레드에 JobService ID를 설정해야 합니다. 예를 들어, 단일 ID에 대한 작업을 처리하는 경우 JobService 컨텍스트에서 JobService ID를 설정하는 것이 좋습니다. 여러 ID에 대한 작업을 처리하는 JobService 경우 스레드 수준에서 ID를 설정하는 것이 좋습니다.

주의

사용하는 WorkManager 앱은 ID를 설정할 때 특별한 주의를 기울여야 합니다. 특히 이러한 앱은 생성자에 Worker 전달된 ID Context 에 ID를 설정하지 않아야 합니다. 이 Context instance는 여러 Worker 인스턴스 간에 동시에 공유할 수 있습니다. 정의되지 않은 동작을 방지하려면 앱이 구현에서 Worker 요구하는 대로 스레드 ID Worker.doWork() 를 대신 설정해야 합니다.

참고

UI CLIPBOARD_SERVICE 에 사용되기 때문에 SDK는 작업에 대한 전경 활동의 UI ID를 사용합니다.ClipboardManager

MAMPolicyManager의 다음 메서드를 사용하여 활성 ID를 설정하고 이전에 설정한 ID 값을 검색할 수 있습니다.

public static void setUIPolicyIdentityOID(final Context context, final String oid,
                    final MAMSetUIIdentityCallback mamSetUIIdentityCallback, final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

편의를 위해 호출하는 대신 MAMPolicyManager.setUIPolicyIdentityOIDMAMActivity의 메서드를 통해 직접 활동의 ID를 설정할 수도 있습니다. 이렇게 하려면 다음 방법을 사용합니다.

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

참고

앱이 매니페스트에서 다중 ID 지원을 선언하지 않은 경우 이러한 메서드를 호출하여 ID를 설정해도 아무 작업도 실행되지 않으며, 를 반환 MAMIdentitySwitchResult하는 경우 항상 을 반환 FAILED합니다.

ID 전환의 일반적인 함정

에 대한 startActivity호출의 경우 Intune 앱 SDK는 해당 수준의 활성 ID Context 가 제공된 Intent 매개 변수와 연결되어 있다고 가정합니다. 의 컨텍스트가 아닌 Application의 컨텍스트로 Activity수준 ID를 설정하는 Context 것이 좋습니다.
활동의 메서드 중에 ID를 Context 설정하는 것이 좋습니다.onCreate 그러나 다음과 같은 onNewIntent다른 진입점도 다루어야 합니다. 그렇지 않으면 동일한 활동을 다시 사용하여 관리되는 ID와 관리되지 않는 ID 모두에 대한 데이터를 표시할 때 정책이 잘못 적용되어 회사 데이터가 보호되지 않거나 개인 데이터가 부적절하게 제한될 수 있습니다.

ID 전환 결과

ID를 설정하는 데 사용되는 모든 메서드는 MAMIdentitySwitchResult를 통해 결과 값을 다시 보고합니다. 반환할 수 있는 값은 네 가지입니다.

반환 값	시나리오
`SUCCEEDED`	ID를 변경했습니다.
`NOT_ALLOWED`	ID 변경은 허용되지 않습니다. 이 문제는 현재 스레드에 다른 ID가 설정되었을 때 UI(`Context`) ID를 설정하려고 할 때 발생합니다.
`CANCELLED`	사용자가 일반적으로 PIN 또는 인증 프롬프트에서 뒤로 단추를 눌러 ID 변경을 취소했습니다.
`FAILED`	지정되지 않은 이유로 ID 변경에 실패했습니다.

앱은 관리되는 계정의 데이터를 표시하거나 사용하기 전에 MAMIdentitySwitchResult 가 있는지 SUCCEEDED 확인해야 합니다.

활성 ID를 설정하는 대부분의 메서드는 MAMIdentitySwitchResult 를 동기적으로 반환합니다. setUIPolicyIdentityOID를 통해 ID를 Context 설정하는 경우 결과가 비동기적으로 보고됩니다. 앱에서 MAMSetUIIdentityCallback 을 구현하여 이 결과를 받거나 콜백 개체에 대해 null을 전달할 수 있습니다. 이전 호출 setUIPolicyIdentityOID 의 결과가 아직 전달되지 않은 상태에서 호출이 이루 setUIPolicyIdentityOID 어지면 새 콜백이 이전 콜백을 대체하고 원래 콜백은 결과를 받지 않습니다.Context

주의

setUIPolicyIdentityOID에 제공된 값이 Context 인 Activity경우, SDK는 관리자가 구성한 조건부 실행 검사를 수행할 때까지 ID 변경이 성공했는지 알 수 없습니다. 이 경우 사용자가 PIN 또는 회사 자격 증명을 입력해야 할 수 있습니다.

현재 프로세스 및 스레드 ID 전환은 다중 ID 사용 앱에 대해 항상 성공합니다. SDK는 향후 실패 조건을 추가할 수 있는 권한을 보유합니다.

UI ID 스위치는 잘못된 인수로 인해 실패하거나, 스레드 ID와 충돌하거나, 사용자가 조건부 실행 요구 사항을 벗어나 취소하는 경우(예: PIN 화면에서 뒤로 단추 누름) 실패할 수 있습니다.

활동에서 실패한 UI ID 스위치의 기본 동작은 활동을 완료하는 것입니다. 이 동작을 변경하고 활동의 ID 변경 시도에 대한 알림을 받으려면 에서 메서드 MAMActivity를 재정의할 수 있습니다.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

재정의 onSwitchMAMIdentityComplete (또는 메서드를 호출) super 하는 경우 ID 전환 실패 후 관리 계정의 데이터가 표시되지 않는지 확인해야 합니다 .

참고

ID를 전환하려면 활동을 다시 만들어야 할 수 있습니다. 이 경우 onSwitchMAMIdentityComplete 콜백은 활동의 새 instance로 전달됩니다.

ID, 의도 및 IdentitySwitchOptions

SDK는 활성 ID로 새 파일에 자동으로 태그를 지정하는 것 외에도 활성 ID로 의도 에 태그를 지정합니다. 기본적으로 SDK는 들어오는 의도의 ID를 검사하고 이를 활성 ID와 비교합니다. 이러한 ID가 일치하지 않으면 SDK는 일반적으로(*) ID 스위치를 요청합니다(자세한 내용은 아래 암시적 ID 변경 사항 참조).

또한 SDK는 나중에 사용할 수 있도록 이 수신 의도 ID를 저장합니다. 앱이 UI ID를 명시적으로 변경하는 경우 SDK는 앱이 전환하려는 ID를 가장 최근에 들어오는 의도 ID와 비교합니다. 이러한 ID가 일치하지 않으면 SDK는 일반적으로 (*) ID 전환에 실패합니다.

SDK는 앱이 의도에 태그된 ID에 속하는 의도의 콘텐츠를 계속 표시하고 있다고 가정하기 때문에 이 검사를 수행합니다. 이 가정은 앱이 관리되는 데이터를 표시할 때 의도치 않게 보호 기능을 끄는 것을 방지합니다. 그러나 이러한 가정은 앱의 실제 동작에 맞지 않을 수 있습니다.

선택적 IdentitySwitchOption 열거형을 setUIPolicyIdentityOID 및 switchMAMIdentityOID API에 전달하여 SDK의 기본 동작을 수정할 수 있습니다.

IGNORE_INTENT: UI 계층에서 ID 전환을 요청할 때 이 옵션은 요청된 ID 매개 변수와 가장 최근에 저장된 의도 ID의 비교를 건너뛰도록 SDK에 알립니다. 이는 앱이 해당 ID에 속하는 콘텐츠를 더 이상 표시하지 않을 때 유용하고 SDK가 이 ID 스위치를 차단해서는 안 됩니다. 예시:
1. 앱이 문서 뷰어입니다. 다른 앱에서 전달된 문서를 렌더링할 수 있습니다. 또한 사용자가 계정을 전환할 수 있는 기능도 포함되어 있습니다. 사용자가 이 계정 전환 기능을 사용할 때마다 앱은 해당 계정의 최근 문서가 있는 계정별 랜딩 페이지로 이동합니다.
2. 앱이 문서를 표시하려는 의도를 수신합니다. 이 의도는 관리 ID로 태그가 지정됩니다.
3. 앱이 관리 ID로 전환되고 보호 기능이 적절하게 적용된 상태로 이 문서가 표시됩니다.
4. 사용자는 계정 전환기를 사용하여 개인 계정으로 변경합니다.
앱에서 4단계에서 UI ID를 변경해야 합니다. 이 경우 앱의 동작은 관리 계정의 데이터(의도의 문서)에서 벗어나는 것이므로 ID 전환 호출에서 사용해야 IGNORE_INTENT 합니다. 이렇게 하면 SDK가 이 호출에 부적절하게 실패하는 것을 방지할 수 있습니다.
DATA_FROM_INTENT: UI 계층에서 ID 전환을 요청할 때 이 옵션은 ID 전환이 성공한 후에도 가장 최근에 저장된 의도 ID의 데이터가 계속 표시될 것이라고 SDK에 알립니다. 결과적으로 SDK는 이전 의도 ID에 대해 수신 정책을 완전히 평가하여 표시가 허용되는지 여부를 결정합니다. 예시:
1. 앱이 문서 뷰어입니다. 다른 앱에서 전달된 문서를 렌더링할 수 있습니다. 또한 사용자가 계정을 전환할 수 있는 기능도 포함되어 있습니다. 위의 예와는 달리, 사용자가 이 계정 전환 기능을 사용할 때마다 앱은 모든 계정에 대한 최근 문서를 보여주는 공유 페이지로 이동합니다.
2. 앱이 문서를 표시하려는 의도를 수신합니다. 이 의도는 관리 ID로 태그가 지정됩니다.
3. 앱이 관리 ID로 전환되고 보호 기능이 적절하게 적용된 상태로 이 문서가 표시됩니다.
4. 사용자는 계정 전환기를 사용하여 개인 계정으로 변경합니다.
앱에서 4단계에서 UI ID를 변경해야 합니다. 이 경우 앱의 동작은 관리 ID의 데이터(의도의 문서 미리 보기)를 계속 표시하는 것이므로 ID 전환 호출에서 사용해야 DATA_FROM_INTENT 합니다. 이렇게 하면 SDK에 구성된 앱 보호 정책을 검사하여 데이터가 계속 표시되는 것이 적절한지 확인하도록 알립니다.

(*) SDK의 기본 동작에는 의도가 동일한 앱 내부 또는 시스템 시작 관리자에서 온 경우 이 데이터 수신 검사를 건너뛰는 특수 케이싱이 포함됩니다.

활성 ID 지우기

애플리케이션에 계정에 관계 없는 시나리오가 있을 수 있습니다. 애플리케이션에 로그인이 필요하지 않은 로컬 관리되지 않는 시나리오가 있을 수도 있습니다. 두 경우 모두 앱에서 SDK가 관리 ID의 정책을 적용하는 것을 원하지 않을 수 있지만 전환할 명시적 ID가 없을 수 있습니다.

ID OID 매개 변수를 로 설정하여 설정된 ID 메서드를 호출하여 활성 ID를 지울 수 있습니다.null 한 수준에서 ID를 지우면 SDK가 우선 순위에 따라 다른 수준에서 활성 ID를 찾습니다.

또는 빈 문자열을 ID OID 매개 변수로 전달하여 ID를 관리되지 않는 ID로 처리되는 특수한 빈 값으로 설정할 수 있습니다. 활성 ID를 빈 문자열로 설정하면 SDK 에 앱 보호 정책을 적용하지 않도록 지시합니다.

암시적 ID 변경

위 섹션에서는 앱에서 스레드, 컨텍스트 및 프로세스 수준에서 활성 ID를 명시적으로 설정할 수 있는 다양한 방법을 설명합니다. 그러나 앱에서 이러한 메서드를 호출하지 않고도 앱의 활성 ID가 변경될 수도 있습니다. 이 섹션에서는 앱이 이러한 암시적 ID 변경을 수신 대기하고 대응하는 방법을 설명합니다.

이러한 암시적 ID 변경 수신 대기는 선택 사항이지만 권장됩니다. SDK는 이러한 암시적 ID 변경 알림을 제공하지 않으면 활성 ID를 변경하지 않습니다.

주의

앱이 암시적 ID 변경을 수신 대기하지 않도록 선택하는 경우 활성 ID를 가정하지 않도록 각별히 주의해야 합니다. 의심스러운 경우 ,, getUIPolicyIdentityOID및 getProcessIdentityOID 메서드를 사용하여 getCurrentThreadIdentityOID활성 ID를 확인합니다.

암시적 ID 변경의 원인

다른 Intune 관리 앱의 데이터 수신은 스레드 및 컨텍스트 수준에서 활성 ID를 변경할 수 있습니다.
- 활동이 다른 MAM 앱에서 보낸 항목 Intent 에서 시작된 경우 활동의 ID는 전송된 시점 Intent 에 다른 앱의 활성 ID를 기반으로 설정됩니다.
  - 예를 들어 사용자가 문서 첨부 파일을 선택하면 Microsoft Outlook의 의도에서 Word 문서를 보는 활동이 시작됩니다. Office의 문서 뷰어 활동 ID가 Outlook의 ID로 전환됩니다.
- 서비스의 경우 스레드 ID는 OR onBind 호출 기간 onStart 동안 유사하게 설정됩니다. 반환된 원본 onBind 에 Binder 대한 호출도 스레드 ID를 일시적으로 설정합니다.
- ContentProvider 호출은 유사하게 해당 기간 동안 스레드 ID를 설정합니다.
활동과의 사용자 상호 작용은 컨텍스트 수준에서 활성 ID를 변경할 수 있습니다. 예시:
- 도중 Resume 사용자가 권한 부여 프롬프트를 취소하면 빈 ID로의 암시적 전환이 발생합니다.

암시적 ID 변경 처리

앱은 필요에 따라 이러한 암시적 ID 변경을 수신 대기하고 반응할 수 있습니다. 예를 들어 새 받은 편지함을 설정하는 전자 메일 앱과 같이 응용 프로그램을 사용하려면 추가된 계정을 사용할 수 있게 하려면 여러 단계가 필요할 수 있습니다. 이 불완전한 계정의 ID로의 ID 전환 시도가 확인되면 앱의 처리기는 ID 전환을 수락하기 전에 사용자를 계정 설정 작업으로 리디렉션할 수 있습니다. 또는 앱의 처리기가 오류 대화 상자를 표시하고 ID 스위치를 차단할 수 있습니다.

앱은 이 스레드에 적용되는 ID 변경에 대해 ServiceMAMIdentityRequirementListenerContextProvider 인터페이스를 구현할 수 있습니다. 구현에서 다음을 재정의해야 합니다.

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

앱은 이 활동에 적용되는 ID 변경에 대해 MAMActivityIdentityRequirementListener 인터페이스를 Activity 구현할 수 있습니다. 구현에서 다음을 재정의해야 합니다.

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

열거형 매개 변수는 AppIdentitySwitchReason 암시적 ID 스위치의 소스를 설명합니다.

열거형 값	기본 SDK 동작	설명
`CREATE`	ID 전환을 허용합니다.	활동 만들기로 인해 ID 전환이 발생합니다.
`NEW_INTENT`	ID 전환을 허용합니다.	새 의도가 활동에 할당되고 있기 때문에 ID 전환이 발생합니다.
`RESUME_CANCELLED`	ID 스위치를 차단합니다.	다시 시작이 취소되었기 때문에 ID 전환이 발생합니다. 이는 최종 사용자가 PIN, 인증 또는 규정 준수 UI에서 뒤로 단추를 누를 때 가장 일반적입니다.

AppIdentitySwitchResultCallback 매개 변수를 사용하면 개발자가 ID 스위치의 기본 동작을 재정의할 수 있습니다.

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired 에서 반환된 MAMService.onMAMBind바인더를 통해 수행된 변경을 제외하고 모든 암시적 ID 변경에 대해 호출됩니다. 즉시 호출의 onMAMIdentitySwitchRequired 기본 구현:

callback.reportIdentitySwitchResult(FAILURE) 이유가 다음과 같은 RESUME_CANCELLED경우.
callback.reportIdentitySwitchResult(SUCCESS) 다른 모든 경우에.

대부분의 앱에서 ID 전환을 다른 방식으로 차단하거나 지연해야 하는 것은 아니지만, 앱에서 이렇게 해야 하는 경우 다음 사항을 고려해야 합니다.

ID 스위치가 차단된 경우 최종 사용자 동작은 SDK의 "다른 앱에서 데이터 수신" 앱 보호 설정이 데이터 수신을 금지한 것과 동일합니다.
서비스가 주 스레드에서 실행 중인 경우 reportIdentitySwitchResult 동기적으로 호출해야 하거나 UI 스레드가 응답하지 않습니다.
생성을 위해 ActivityonMAMIdentitySwitchRequired 가 이전에 onMAMCreate호출됩니다. 앱에서 ID 전환 허용 여부를 결정하기 위해 UI를 표시해야 하는 경우 해당 UI는 다른 활동을 사용하여 표시되어야 합니다.
에서 Activity, 빈 ID로의 전환이 이유와 RESUME_CANCELLED함께 요청되면 앱은 해당 ID 전환과 일치하는 데이터를 표시하도록 재개된 활동을 수정해야 합니다. 이렇게 할 수 없는 경우 앱은 전환을 거부해야 하며, 사용자는 다시 시작 ID에 대한 정책을 준수하라는 메시지가 다시 표시됩니다(예: 앱 PIN 입력 화면이 표시됨).

주의

다중 ID 앱은 관리되는 앱과 관리되지 않는 앱 모두에서 들어오는 데이터를 받을 수 있습니다. 관리 ID의 데이터를 관리되는 방식으로 처리하는 것은 앱의 책임입니다.

요청된 ID가 관리되지만(MAMPolicyManager.getIsIdentityOIDManaged 사용을 사용하여 검사) 앱에서 해당 계정을 사용할 수 없는 경우(예: 이메일 계정과 같은 계정을 앱에서 먼저 설정해야 하기 때문에) ID 전환을 거부해야 합니다.

의 MAMActivity.onMAMIdentitySwitchRequired 기본 동작은 정적 메서드 MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)를 호출하여 액세스할 수 있습니다.

마찬가지로 , 를 재정의MAMActivity.onSwitchMAMIdentityComplete해야 하는 경우 명시적으로 상속하지 않고 구현MAMActivity할 수 있습니다MAMActivityIdentitySwitchListener.

ID 전환 및 스크린샷 제한

Intune 앱 SDK는 플래그 FLAG_SECURE 를 Window 사용하여 스크린샷 정책을 적용합니다. 일부 앱은 자체 용도에 맞게 설정할 FLAG_SECURE 수도 있습니다. 앱 보호 정책이 스크린샷을 제한하지 않는 경우 SDK는 FLAG_SECURE.

정책에서 스크린샷을 사용하지 않도록 설정해야 하는 ID에서 정책이 요구하지 않는 ID로 ID를 전환하면 SDK가 지웁 FLAG_SECURE니다. 따라서 앱은 ID 전환 후 나머지 집합에 FLAG_SECURE 의존해서는 안 됩니다.

비동기 작업에서 ID 유지

앱은 종종 UI 스레드에서 백그라운드 작업을 디스패치하여 다른 스레드에서 작업을 처리합니다. 다중 ID 앱은 이러한 백그라운드 작업이 디스패치한 활동에서 사용하는 것과 동일한 적절한 ID로 작동하도록 해야 합니다.

Intune 앱 SDK는 비동기 작업에서 ID를 유지하는 데 도움이 되는 편의를 위해 MAMAsyncTask 및 MAMIdentityExecutors를 제공합니다. 비동기 작업이 다음을 수행할 수 있는 경우 앱에서 이를 사용하거나 작업에서 스레드 ID를 명시적으로 설정해야 합니다.

관리 ID에 속한 데이터를 파일에 쓰기
다른 앱과 통신

MAMAsyncTask

를 사용하려면 MAMAsyncTask, 대신 단순히 상 AsyncTask 속하고 및 및 onPreExecute 의 재정의를 doInBackground 각각 및 및 등 onPreExecuteMAM 으로 doInBackgroundMAM 바꿉니다. MAMAsyncTask 생성자는 활동 컨텍스트를 사용합니다. 예시:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask 일반적인 우선 순위에 따라 활성 ID로 가정합니다.

MAMIdentityExecutors

MAMIdentityExecutors를 사용하면 AND Executor 메서드로 기존 또는 ExecutorService instance를 ID 보존ExecutorExecutorService/으로 래핑할 수 있습니다.wrapExecutorwrapExecutorService 예를 들면 다음과 같습니다.

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors 일반적인 우선 순위에 따라 활성 ID로 가정합니다.

파일 보호

보호된 Files 쓰기

위의 ID별 앱 데이터 구성에서 설명한 대로 Intune 앱 SDK는 활성 ID(스레드/프로세스 수준에서)를 작성되는 파일과 연결합니다. 적절한 암호화 및 선택적 초기화 기능을 보장하려면 파일을 만들 때 올바른 ID를 설정하는 것이 중요합니다.

앱에서 MAMFileProtectionManager 클래스(특히 MAMFileProtectionManager.getProtectionInfo 쿼리 및 MAMFileProtectionManager.protectForOID 변경용)를 사용하여 파일의 ID를 쿼리하거나 변경할 수 있습니다.

이 protectForOID 메서드를 사용하여 디렉터리를 보호할 수도 있습니다. 디렉터리 보호는 디렉터리에 포함된 모든 파일 및 하위 디렉터리에 재귀적으로 적용됩니다. 디렉터리가 보호되면 디렉터리 내에서 만들어지는 모든 새 파일에 동일한 보호가 자동으로 적용됩니다. 디렉터리 보호가 재귀적으로 적용되기 때문에 큰 디렉터리의 경우 호출을 protectForOID 완료하는 데 다소 시간이 걸릴 수 있습니다. 이러한 이유로 많은 수의 파일이 포함된 디렉터리에 보호를 적용하는 앱은 백그라운드 스레드에서 비동기적으로 실행 protectForOID 되기를 원할 수 있습니다.

ID 매개 변수에 빈 문자열을 사용하여 호출 protectForOID 하면 관리되지 않는 ID로 파일/디렉터리에 태그가 지정됩니다. 이 작업을 수행하면 파일/디렉터리에서 이전에 암호화된 암호화가 제거됩니다. 선택적 지우기 명령이 실행되면 파일/디렉터리가 삭제되지 않습니다.

경고

특정 ID에 속한 파일만 해당 ID로 보호되도록 하는 것이 중요합니다. 그렇지 않으면 소유 ID가 로그아웃할 때 파일이 지워지고 암호화 키 액세스 권한이 손실되어 다른 ID의 데이터 손실이 발생할 수 있습니다.

보호된 파일 콘텐츠 표시

권한 없는 사용자가 관리 데이터를 볼 수 없도록 파일 콘텐츠가 표시 될 때 올바른 ID를 설정하는 것도 마찬가지로 중요합니다. SDK는 읽는 파일과 .s에 표시되는 데이터 사이의 관계를 자동으로 유추할 수 없습니다.Activity 앱은 관리 데이터를 표시하기 전에 UI ID를 적절하게 설정 해야 합니다 . 여기에는 파일에서 읽은 데이터가 포함됩니다.

파일이 앱 ContentProvider 외부에서 가져오거나 공개적으로 쓰기 가능한 위치에서 읽은 경우 앱은 파일 에서 읽은 정보를 표시하기 전에 파일 ID를 확인해야 합니다(데이터 원본에 대한 올바른 MAMFileProtectionManager.getProtectionInfo 오버로드 사용).

null이 아니고 비어 있지 않은 ID를 보고하는 경우 getProtectionInfo 앱은 MAMActivity.switchMAMIdentityOID 또는 MAMPolicyManager.setUIPolicyIdentityOID를 사용하여 이 ID와 일치하도록 UI ID를 설정해야 합니다. ID 전환이 실패하면 파일의 데이터가 표시되지 않아야 합니다 .

콘텐츠 URI에서 읽을 때 먼저 ID를 읽은 다음(오버Uri로드를 통해 getProtectionInfo ) 컨텍스트 또는 스레드 ID를 적절하게 설정해야 할 수 있습니다. 에서 파일 설명자 또는 입력 스트림을 열기 전에 이 작업을 수행해야 합니다. ContentResolver그렇지 않으면 작업이 실패할 수 있습니다.

흐름의 예시는 다음과 같을 수 있습니다.

사용자가 앱에서 열 문서를 선택합니다.

열기 흐름 중에 디스크에서 데이터를 읽기 전에 앱은 콘텐츠를 표시하는 데 사용해야 하는 ID를 확인합니다.

MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
if (info != null)
    MAMPolicyManager.setUIPolicyIdentityOID(activity, info.getIdentityOID(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)

앱은 결과가 콜백에 보고될 때까지 기다립니다.
보고된 결과가 실패인 경우 앱에 문서가 표시되지 않습니다.
앱이 열리고 파일이 렌더링됩니다.

앱이 Android DownloadManager 를 사용하여 파일을 다운로드하는 경우 SDK는 앞에서 설명한 ID 우선 순위를 사용하여 이러한 파일을 자동으로 보호하려고 시도합니다. 스레드 ID가 설정되지 않은 경우 검색 DownloadManager 하는 데 사용되는 컨텍스트가 사용됩니다. 다운로드한 파일에 회사 데이터가 포함된 경우 다운로드 후 파일을 이동하거나 다시 만드는 경우 앱이 protectForOID 를 호출해야 합니다.

Single-Identity 다중 ID로 전환

이전에 단일 ID Intune 통합으로 릴리스된 앱이 나중에 다중 ID를 통합하는 경우 이전에 설치된 앱은 전환을 경험합니다. 이 전환은 사용자에게 표시되지 않습니다.

앱이 이 전환을 처리할 필요는 없습니다 . 전환 전에 생성된 모든 파일은 계속 관리되는 것으로 간주됩니다(따라서 암호화 정책이 켜져 있는 경우 암호화된 상태로 유지됨).

이전의 모든 앱 데이터가 관리 ID와 연결되지 않도록 하려면 이 전환을 감지하고 보호를 명시적으로 제거할 수 있습니다.

앱 버전을 다중 ID 지원이 추가된 알려진 버전과 비교하여 업그레이드를 감지합니다.
관리 ID와 연결하지 않으려는 파일 또는 디렉터리의 ID 매개 변수에 대해 빈 문자열을 사용하여 호출 protectForOID 합니다.

오프라인 시나리오

Intune 앱 SDK는 회사 포털 앱이 설치되지 않은 경우 "오프라인" 모드로 실행됩니다. 파일 ID 태그 지정은 오프라인 모드에 민감합니다.

회사 포털이 설치되어 있지 않으면 파일에 ID 태그를 지정할 수 없습니다. 오프라인 모드에서 MAMFileProtectionManager.protectForOID 를 호출하는 것은 안전하지만 아무런 영향을 주지 않습니다.
회사 포털이 설치되어 있지만 앱에 앱 보호 정책이 없는 경우 파일에 ID 태그를 안정적으로 지정할 수 없습니다.
파일 ID 태그 지정을 사용할 수 있게 되면 단일 ID에서 다중 ID로 전환에 설명된 대로 앱이 이전에 단일 ID 관리 앱으로 설치된 경우를 제외하고 이전에 생성된 모든 파일은 개인/관리되지 않은(빈 문자열 ID에 속함) 처리됩니다.

이러한 경우를 방지하려면 계정 등록이 성공적으로 완료될 때까지 앱에서 계정 데이터가 포함된 파일을 생성하지 않아야 합니다. 앱이 오프라인 상태일 때 반드시 파일을 만들어야 하는 경우 SDK가 온라인 상태가 되면 MAMFileProtectionManager.protectForOID 를 사용하여 파일의 연결된 ID를 수정할 수 있습니다.

데이터 버퍼 보호

경고

여러 계정에 속한 데이터를 단일 파일에 쓰는 것은 권장되지 않습니다. 가능하면 ID별로 앱의 파일을 구성합니다.

SDK의 MAMDataProtectionManager 는 특정 데이터 버퍼 byte[]InputStream 에서 태그가 지정된 ID를 또는 형식으로 확인하고 변경하는 메서드를 제공합니다.

MAMDataProtectionManager.protectForOID 앱에서 데이터를 ID와 연결하고, ID가 현재 암호화 정책의 대상인 경우 데이터를 암호화할 수 있습니다. 이 암호화된 데이터는 디스크에 파일을 저장하는 데 적합합니다.

MAMDataProtectionManager 또한 ID와 연결된 데이터를 쿼리하고 암호화를 해제할 수 있습니다.

을 MAMDataProtectionManager 사용하는 앱은 알림에 대한 수신기를 구현해야 합니다.MANAGEMENT_REMOVED 자세한 내용은 SDK의 알림 등록을 참조하세요.

이 알림이 완료되면 이 클래스를 통해 보호되었던 버퍼를 더 이상 읽을 수 없습니다(버퍼가 보호될 때 파일 암호화가 활성화된 경우). 앱은 알림을 처리할 때 모든 버퍼를 호출 MAMDataProtectionManager.unprotect 하여 이러한 버퍼를 읽을 수 없게 할 수 없습니다.MANAGEMENT_REMOVED ID 정보를 보존하려는 경우 이 알림 중에 호출 protectForOID 하는 것도 안전합니다. 암호화는 알림 중에 비활성화되도록 보장되며 처리기에서 호출 protectForOID 해도 데이터 버퍼는 암호화되지 않습니다.

경고

앱 프로세스 초기에 암호화 작업을 피해야 합니다. SDK는 앱 시작 후 가능한 한 빨리 암호화 초기화를 비동기식으로 수행합니다. 그러나 앱 시작 시 앱이 암호화 요청을 하면 암호화 초기화가 완료될 때까지 차단될 수 있습니다.

참고

Intune 앱 SDK 암호화 API는 Intune 정책에서 요구하는 대로 데이터를 암호화하는 데만 사용해야 합니다. 암호화 정책을 사용하도록 설정된 대상으로 지정되지 않은 계정에는 보호가 적용되지 않으므로 범용 암호화 라이브러리로 사용할 수 없습니다.

콘텐츠 공급자

또한 다중 ID 앱은 관리 콘텐츠의 부적절한 공유를 방지하기 위해 s를 통해 ContentProvider공유되는 데이터를 보호해야 합니다.

앱은 콘텐츠를 반환하기 전에 정적 MAMContentProvider 메서드 isProvideContentAllowedForOid(provider, oid) 를 호출해야 합니다. 이 함수가 false를 반환하는 경우 콘텐츠가 호출자에게 반환 되지 않아야 합니다 .

반환 ContentProvider 하는 경우 호출 isProvideContentAllowedForOid 할 필요가 없습니다.ParcelFileDescriptor 콘텐츠 공급자를 통해 반환된 파일 설명자는 파일 ID에 따라 자동으로 처리됩니다.

선택적 초기화

기본적으로 Intune 앱 SDK는 선택 지우기를 자동으로 처리하여 관리 ID와 연결된 모든 파일을 삭제합니다. 그런 다음 SDK가 앱을 정상적으로 닫아 활동을 완료하고 앱 프로세스를 종료합니다.

SDK는 앱에서 기본 초기화 동작을 보완(권장)하거나 재정의할 수 있는 선택적 기능을 제공합니다.

SDK의 기본 초기화 처리기는 로 보호되는 데이터 버퍼를 처리하지 않습니다.MAMDataProtectionManager 앱에서 이 기능을 사용한 경우 해당 데이터를 제거하려면 기본 초기화 처리기를 보완하거나 재정의 해야 합니다.

참고

기본 초기화 동작을 보완하고 재정의하려면 특정 SDK 알림을 처리해야 합니다. 알림 처리기 구현에 대한 자세한 내용은 SDK에서 알림 등록을 참조하세요.

기본 지우기 동작 보완

기본 SDK 초기화 동작을 보완하기 위해 앱이 MAMNotificationType에 등록 WIPE_USER_AUXILIARY_DATA 할 수 있습니다.

이 알림은 SDK가 기본 선택적 초기화를 수행 하기 전에 전송합니다. SDK는 데이터를 삭제하고 앱을 종료하기 전에 앱의 알림 처리기가 완료될 때까지 기다립니다. 앱은 동기적으로 데이터를 지우고 모든 정리가 완료될 때까지 반환하지 않아야 합니다.

앱별 정리는 다중 ID 앱에 일반적이므로 앱은 다음으로 WIPE_USER_AUXILIARY_DATA기본 초기화 동작을 보완하는 것을 적극 고려해야 합니다.

기본 지우기 동작 재정의

기본 SDK 초기화 동작을 재정의하려면 앱에서 MAMNotificationType을 등록 WIPE_USER_DATA 할 수 있습니다.

경고

WIPE_USER_DATA 앱은 및 WIPE_USER_AUXILIARY_DATA.

기본 SDK 초기화 동작을 재정의하면 앱이 상당한 위험을 초래합니다. 앱은 해당 ID에 대해 태그가 지정된 모든 파일 및 데이터 버퍼를 포함하여 관리 ID와 연결된 모든 데이터를 제거해야 할 완전한 책임이 있습니다.

관리 ID가 암호화로 보호되고 앱의 사용자 지정 초기화 처리기가 모든 관리 데이터를 완전히 제거하지 않는 경우 나머지 관리 파일은 암호화된 상태로 유지됩니다. 이 데이터는 액세스할 수 없게 되고 앱에서 암호화된 데이터를 정상적으로 읽으려는 시도를 처리하지 못할 수 있습니다.
앱의 초기화 처리기가 관리 ID로 태그가 지정되지 않은 파일을 제거하는 경우 관리되지 않는 사용자의 데이터 손실이 발생할 수 있습니다.

앱의 사용자 지정 초기화 처리기가 파일에서 관리 데이터를 제거하지만 파일에 다른 데이터를 남기려면 MAMFileProtectionManager.protectForOID를 통해 파일의 ID를 관리되지 않는 ID 또는 빈 문자열로 변경해야 합니다.

재정의된 초기화 처리기는 동기적으로 데이터를 지우고 모든 정리가 완료될 때까지 반환하지 않아야 합니다.

사용자 지정 초기화 처리기 단계를 완료한 후 수동으로 앱을 닫아 초기화가 발생한 후 사용자가 메모리 내 데이터에 액세스하지 못하도록 하는 것이 좋습니다.

종료 조건

앱의 다중 ID 통합을 검증하는 데 상당한 시간을 할애할 계획입니다. 테스트를 시작하기 전에:

앱 보호 정책을 만들고 계정에 할당합니다. 테스트 관리 계정이 됩니다.
다른 계정을 만들되 앱 보호 정책을 할당하지는 않습니다. 이 계정은 테스트 비관리형 계정이 됩니다. 또는 앱에서 Microsoft Entra 계정 이외의 여러 계정 유형을 지원하는 경우 기존의 비 Entra 계정을 관리되지 않는 테스트 계정으로 사용할 수 있습니다.
앱 내에서 정책이 시행되는 방법을 다시 숙지하세요. 다중 ID 테스트를 수행하려면 앱이 정책이 적용된 상태에서 언제 작동하고 있고 언제 작동하지 않는지를 쉽게 구분할 수 있습니다. 스크린샷을 차단하는 앱 보호 정책 설정은 정책 적용을 신속하게 테스트하는 데 효과적입니다.
앱에서 제공하는 전체 UI 집합을 고려하세요. 계정 데이터가 표시되는 화면을 열거합니다. 앱이 한 번에 단일 계정의 데이터만 표시하나요, 아니면 여러 계정에 속하는 데이터를 동시에 표시할 수 있나요?
앱에서 만드는 전체 파일 집합을 고려하세요. 시스템 수준 데이터가 아닌 계정에 속한 데이터가 포함된 파일을 열거합니다.
- 이러한 각 파일에서 암호화의 유효성을 검사할 방법을 결정합니다.
앱이 다른 앱과 상호 작용할 수 있는 전체 방법을 고려합니다. 모든 수신 및 송신 지점을 열거합니다. 앱에서 어떤 유형의 데이터를 수집할 수 있나요? 어떤 의도를 브로드캐스트하나요? 어떤 콘텐츠 공급자를 구현하나요?
- 이러한 각 데이터 공유 기능을 실행할 방법을 결정합니다.
- 앱과 상호 작용할 수 있는 관리되는 앱과 관리되지 않는 앱이 모두 있는 테스트 디바이스를 준비합니다.
앱에서 최종 사용자가 로그인한 모든 계정과 상호 작용할 수 있도록 하는 방법을 고려합니다. 해당 계정의 데이터가 표시되기 전에 사용자가 수동으로 계정으로 전환해야 하나요?

앱의 현재 동작을 철저히 평가한 후 다음 테스트 집합을 실행하여 다중 ID 통합의 유효성을 검사합니다. 이 목록은 포괄적인 목록이 아니며 앱의 다중 ID 구현에 버그가 없다는 보장은 없습니다.

다중 ID 앱은 최대 1개의 관리 계정과 여러 개의 관리되지 않는 계정을 지원합니다. 이러한 테스트는 다중 ID 통합이 사용자가 로그인하거나 로그아웃할 때 보호 기능을 부적절하게 변경하지 않도록 하는 데 도움이 됩니다.

이러한 테스트를 위해 앱과 Intune 회사 포털을 설치합니다. 테스트를 시작하기 전에 로그인하지 마세요.

시나리오	단계
먼저 관리되는 로그인	- 먼저 관리 계정으로 로그인하고 계정의 데이터가 관리되는지 확인합니다. - 관리되지 않는 계정으로 로그인하고 계정의 데이터가 관리되지 않는지 확인합니다.
비관리형 먼저 로그인	- 먼저 관리되지 않는 계정으로 로그인하고 계정의 데이터가 관리되지 않는지 확인합니다. - 관리 계정으로 로그인하고 계정 데이터가 관리되는지 확인합니다.
여러 관리형 로그인	- 먼저 관리 계정으로 로그인하고 계정의 데이터가 관리되는지 확인합니다. - 두 번째 관리 계정으로 로그인하고 원래 관리 계정을 먼저 제거하지 않고는 사용자가 로그인할 수 없도록 차단되었는지 확인합니다.
로그아웃 관리됨	- 관리되는 계정과 관리되지 않는 계정 모두를 사용하여 앱에 로그인합니다. - 관리 계정에서 로그아웃합니다. - 관리 계정이 앱에서 삭제되었고 해당 계정의 데이터가 모두 삭제되었는지 확인합니다. - 관리되지 않는 계정이 여전히 로그인되어 있고, 관리되지 않는 계정의 데이터가 제거되지 않았으며, 정책이 여전히 적용되지 않는지 확인합니다.
관리되지 않는 로그아웃	- 관리되는 계정과 관리되지 않는 계정 모두를 사용하여 앱에 로그인합니다. - 관리되지 않는 계정에서 로그아웃합니다. - 관리되지 않는 계정이 앱에서 삭제되었으며 해당 계정의 모든 데이터가 삭제되었는지 확인합니다. - 관리 계정이 여전히 로그인되어 있고, 관리되지 않는 계정의 데이터가 제거되지 않았으며, 정책이 계속 적용되는지 확인합니다.

활성 ID 및 앱 수명 주기 유효성 검사

다중 ID 앱은 단일 계정의 데이터로 보기를 표시할 수 있으며 사용자가 현재 사용 중인 계정을 명시적으로 변경할 수 있도록 허용할 수 있습니다. 또한 여러 계정의 데이터가 동시에 있는 보기를 표시할 수도 있습니다. 이러한 테스트는 다중 ID 통합이 전체 앱 수명 주기 동안 모든 페이지에서 활성 ID에 대한 적절한 보호를 제공하는지 확인하는 데 도움이 됩니다.

이러한 테스트를 위해 앱과 Intune 회사 포털을 설치합니다. 테스트를 시작하기 전에 관리 계정과 관리되지 않는 계정 모두로 로그인합니다.

시나리오	단계
단일 계정 보기, 관리됨	- 관리 계정으로 전환합니다. - 단일 계정의 데이터가 표시되는 앱의 모든 페이지로 이동합니다. - 정책이 모든 페이지에 적용되는지 확인합니다.
단일 계정 보기, 관리되지 않음	- 관리되지 않는 계정으로 전환합니다. - 단일 계정의 데이터가 표시되는 앱의 모든 페이지로 이동합니다. - 정책이 어떤 페이지에도 적용되지 않는지 확인합니다.
다중 계정 보기	- 여러 계정의 데이터가 동시에 표시되는 앱의 모든 페이지로 이동합니다. - 정책이 모든 페이지에 적용되는지 확인합니다.
관리되는 일시 중지	- 관리되는 데이터가 표시되고 정책이 활성화된 화면에서 장치 홈 화면 또는 다른 앱으로 이동하여 앱을 일시 중지합니다. - 앱을 다시 시작합니다. - 정책이 계속 적용되는지 확인합니다.
관리되지 않는 일시 중지	- 관리되지 않는 데이터가 표시되고 활성 상태인 정책이 없는 화면에서 장치 홈 화면 또는 다른 앱으로 이동하여 앱을 일시 중지합니다. - 앱을 다시 시작합니다. - 정책이 적용되지 않는지 확인합니다.
관리되는 킬	- 관리 데이터가 표시되고 정책이 활성화된 화면에서 앱을 강제 종료합니다. - 앱을 다시 시작합니다. - 관리 계정의 데이터가 있는 화면에서 앱이 다시 시작되면 정책이 계속 적용되는지 확인합니다. 관리되지 않는 계정의 데이터가 있는 화면에서 앱이 다시 시작되면 정책이 적용되지 않는지 확인합니다.
관리되지 않는 킬	- 관리되지 않는 데이터가 표시되고 정책이 활성화된 화면에서 앱을 강제 종료합니다. - 앱을 다시 시작합니다. - 관리되지 않는 계정의 데이터가 있는 화면에서 앱이 다시 시작되면 정책이 적용되지 않는지 확인합니다. 관리되는 계정의 데이터가 있는 화면에서 앱이 다시 시작되면 정책이 여전히 적용되는지 확인합니다.
ID 전환 임시	- 계정 간 전환 및 앱 일시 중지/다시 시작/중단/재시작을 실험합니다. - 관리 계정의 데이터는 항상 보호되고 비관리 계정의 데이터는 절대 보호되지 않는지 확인합니다.

다중 ID 앱은 다른 앱과 데이터를 주고받을 수 있습니다. Intune의 앱 보호 정책에는 이 동작을 지시하는 설정이 있습니다. 이러한 테스트는 다중 ID 통합이 이러한 데이터 공유 설정을 준수하는지 확인하는 데 도움이 됩니다.

이러한 테스트를 위해 앱과 Intune 회사 포털을 설치합니다. 테스트를 시작하기 전에 관리 계정과 관리되지 않는 계정 모두로 로그인합니다. 또한

관리되는 계정의 정책을 다음과 같이 설정합니다.
- "다른 앱으로 조직 데이터 보내기"를 "정책 관리 앱"으로 변경했습니다.
- "다른 앱에서 데이터 받기"를 "정책 관리 앱"으로 변경했습니다.
테스트 장치에 다른 앱을 설치합니다.
- 앱과 동일한 정책으로 대상으로 지정되고 데이터를 보내고 받을 수 있는 관리형 앱(예: Microsoft Outlook).
- 데이터를 보내고 받을 수 있는 모든 관리되지 않는 앱입니다.
관리되는 테스트 계정으로 다른 관리되는 앱에 로그인합니다. 다른 관리되는 앱이 다중 ID인 경우에도 관리되는 계정으로만 로그인합니다.

앱이 Microsoft Office에 문서 첨부 파일을 보내는 Microsoft Outlook과 같은 다른 앱으로 데이터를 보내는 기능이 있는 경우:

시나리오	단계
관리 ID가 관리되지 않는 앱으로 보내짐	- 관리 계정으로 전환합니다. - 앱에서 데이터를 전송할 수 있는 위치로 이동합니다. - 관리되지 않는 앱으로 데이터를 보내려고 시도합니다. - 관리되지 않는 앱으로 데이터를 보내지 못하도록 차단되어야 합니다.
관리 ID가 관리 앱으로 보내짐	- 관리 계정으로 전환합니다. - 앱에서 데이터를 전송할 수 있는 위치로 이동합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱으로 데이터를 보내려고 시도합니다. - 관리되는 앱으로 데이터를 보낼 수 있어야 합니다.
관리되지 않는 ID 관리되는 앱으로 보내기	- 관리되지 않는 계정으로 전환합니다. - 앱에서 데이터를 전송할 수 있는 위치로 이동합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱으로 데이터를 보내려고 시도합니다. - 다른 관리되는 앱으로 데이터를 보낼 수 없도록 차단되어야 합니다.
관리되지 않는 ID 관리되지 않는 앱으로 보내기	- 관리되지 않는 계정으로 전환합니다. - 앱에서 데이터를 전송할 수 있는 위치로 이동합니다. - 관리되지 않는 앱으로 데이터를 보내려고 시도합니다. - 관리되지 않는 계정의 데이터를 관리되지 않는 앱으로 보낼 수 있어야 합니다.

앱은 Microsoft OneDrive에서 파일을 첨부하는 Microsoft Outlook과 같은 다른 앱에서 데이터를 적극적으로 가져올 수 있습니다. 앱은 Microsoft Office Microsoft Outlook 첨부 파일에서 문서를 여는 것과 같은 다른 앱에서 데이터를 수동으로 수신할 수도 있습니다. 앱 보호 정책 설정 수신은 두 가지 시나리오를 모두 다룹니다.

앱이 다른 앱에서 데이터를 적극적으로 가져올 수 있는 기능이 있는 경우:

시나리오	단계
관리되지 않는 앱에서 관리 ID 가져오기	- 관리 계정으로 전환합니다. - 앱이 다른 앱의 데이터를 가져올 수 있는 위치로 이동합니다. - 관리되지 않는 앱에서 데이터를 가져오려고 시도합니다. - 관리되지 않는 앱에서 데이터를 가져올 수 없도록 차단되어야 합니다.
관리되는 앱에서 관리 ID 가져오기	- 관리 계정으로 전환합니다. - 앱이 다른 앱의 데이터를 가져올 수 있는 위치로 이동합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱에서 데이터를 가져오려고 시도합니다. - 다른 관리되는 앱에서 데이터를 가져올 수 있어야 합니다.
관리되는 앱에서 비관리 ID 가져오기	- 관리되지 않는 계정으로 전환합니다. - 앱이 다른 앱의 데이터를 가져올 수 있는 위치로 이동합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱에서 데이터를 가져오려고 시도합니다. - 다른 관리되는 앱에서 데이터를 가져올 수 없도록 차단되어야 합니다.
관리되지 않는 앱에서 비관리 ID 가져오기	- 관리되지 않는 계정으로 전환합니다. - 앱이 다른 앱의 데이터를 가져올 수 있는 위치로 이동합니다. - 관리되지 않는 앱에서 데이터를 가져오려고 시도합니다. - 관리되지 않는 계정의 경우 관리되지 않는 앱에서 항상 데이터를 가져올 수 있어야 합니다.

앱이 다른 앱으로부터 데이터를 수동적으로 수신할 수 있는 기능이 있는 경우:

시나리오	단계
관리 ID가 관리되지 않는 앱에서 수신	- 관리 계정으로 전환합니다. - 관리되지 않는 앱으로 전환합니다. - 데이터를 보낼 수 있는 위치로 이동합니다. - 관리되지 않는 앱에서 앱으로 데이터를 보내려고 시도합니다. - 앱의 관리 계정은 관리되지 않는 앱에서 데이터를 수신할 수 없어야 합니다.
관리 ID가 관리되는 앱에서 수신	- 관리 계정으로 전환합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱으로 전환합니다. - 데이터를 보낼 수 있는 위치로 이동합니다. - 관리되는 앱에서 앱으로 데이터를 보내려고 시도합니다. - 앱의 관리 계정이 다른 관리되는 앱에서 데이터를 받을 수 있어야 합니다.
관리되지 않는 ID가 관리 앱에서 수신	- 관리되지 않는 계정으로 전환합니다. - 관리 계정이 로그인되어 있는 다른 관리되는 앱으로 전환합니다. - 데이터를 보낼 수 있는 위치로 이동합니다. - 관리되는 앱에서 앱으로 데이터를 보내려고 시도합니다. - 앱의 관리되지 않는 계정은 관리 앱에서 데이터를 받을 수 없어야 합니다.
관리되지 않는 앱에서 받은 비관리 ID	- 관리되지 않는 계정으로 전환합니다. - 관리되지 않는 앱으로 전환합니다. - 데이터를 보낼 수 있는 위치로 이동합니다. - 관리되지 않는 앱에서 앱으로 데이터를 보내려고 시도합니다. - 앱의 관리되지 않는 계정은 항상 관리되지 않는 앱에서 데이터를 받을 수 있어야 합니다.

이러한 테스트에서 실패했다면 앱이 데이터를 보내거나 받으려고 할 때 올바른 활성 ID가 설정되어 있지 않은 것일 수 있습니다. 보내고/받는 시점에 SDK의 ID 가져오기 API를 활용하여 활성 ID가 제대로 설정되었는지 확인하여 이를 조사할 수 있습니다.

선택적 초기화 시나리오 유효성 검사

다중 ID 앱이 SDK의 기본 지우기 동작을 보완하거나 재정의했을 수 있습니다. 이러한 테스트는 다중 ID 통합이 초기화가 시작될 때 관리되지 않는 데이터에 영향을 주지 않고 관리되는 데이터를 제대로 제거하는지 확인하는 데 도움이 됩니다.

경고

미리 알림으로, 앱에서 를 활용한 MAMDataProtectionManager.protectForOID경우 또는 WIPE_USER_DATA에 대한 WIPE_USER_AUXILIARY_DATA 처리기를 구현해야 합니다.

이러한 테스트를 위해 앱과 Intune 회사 포털을 설치합니다. 테스트를 시작하기 전에 관리 계정과 관리되지 않는 계정 모두로 로그인합니다. 두 계정에 대해 계정 데이터를 저장하는 앱 시나리오를 연습합니다.

시나리오	전제 조건	단계
추가 초기화 처리기	앱에서 다음에 대한 처리기를 구현했습니다. `WIPE_USER_AUXILIARY_DATA`	- Microsoft Intune 관리 센터에서 선택적 초기화를 실행합니다. - 초기화 처리기가 성공적으로 실행되었는지 확인합니다(일반적으로 로깅을 통해). - 관리 계정이 앱에서 삭제되었고 해당 계정의 데이터가 모두 삭제되었는지 확인합니다. - 관리되지 않는 계정이 여전히 로그인되어 있고, 관리되지 않는 계정의 데이터가 제거되지 않았으며, 정책이 여전히 적용되지 않는지 확인합니다.
재정의된 초기화 처리기	앱에서 다음에 대한 처리기를 구현했습니다. `WIPE_USER_DATA`	- Microsoft Intune 관리 센터에서 선택적 초기화를 실행합니다. - 초기화 처리기가 성공적으로 실행되었는지 확인합니다(일반적으로 로깅을 통해). - 관리 계정이 앱에서 삭제되었고 해당 계정의 데이터가 모두 삭제되었는지 확인합니다. - 관리되지 않는 계정이 여전히 로그인되어 있고, 관리되지 않는 계정의 데이터가 제거되지 않았으며, 정책이 여전히 적용되지 않는지 확인합니다. - 앱이 정상적으로 종료되었는지 또는 초기화 처리기가 완료된 후에도 여전히 정상 상태인지 확인합니다.
수동 파일 보호	- 앱에서 호출 `MAMFileProtectionManager.protectForOID` - 앱에서 다음에 대한 처리기를 구현했습니다. `WIPE_USER_DATA`	- 앱이 관리 계정에 속한 파일 하나 이상을 수동으로 보호하는 시나리오를 실행했는지 확인합니다. - Microsoft Intune 관리 센터에서 선택적 초기화를 실행합니다. - 파일이 제거되었는지 확인합니다.
수동 데이터 버퍼 보호	- 앱에서 호출 `MAMDataProtectionManager.protectForOID` - 앱에서 다음 중 하나 `WIPE_USER_AUXILIARY_DATA` 에 대한 처리기를 구현했습니다. `WIPE_USER_DATA`	- 앱에서 관리 계정에 속하는 하나 이상의 데이터 버퍼를 수동으로 보호하는 시나리오를 실행했는지 확인합니다. - Microsoft Intune 관리 센터에서 선택적 초기화를 실행합니다. - 데이터 버퍼가 저장된 파일에서 제거되었으며 앱이 해당 파일에서 관리되지 않는 데이터를 계속 읽을 수 있는지 확인합니다.

다음 단계

위의 모든 종료 조건 을 완료하면 이제 앱이 다중 ID로 성공적으로 통합되고 ID별로 앱 보호 정책을 적용할 수 있습니다. 후속 섹션인 6단계: App Configuration 및 7단계: 앱 참여 기능은 앱에서 원하는 앱 보호 정책 지원에 따라 필요할 수도 있고 필요하지 않을 수도 있습니다. 이러한 섹션 중 앱에 적용되는지 확실하지 않은 경우 SDK 통합을 위한 주요 결정을 다시 검토하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-04-09