Microsoft Azure(Microsoft 365) API용 Cisco Secure Email Account 설정 구성 방법

소개

이 문서에서는 Microsoft Azure(Azure Active Directory)에서 새 응용 프로그램을 등록하여 필요한 클라이언트 ID, 테넌트 ID 및 클라이언트 자격 증명을 생성한 다음 Cisco Secure Email Gateway 또는 Cloud Gateway에서 계정 설정에 대한 구성을 생성하는 단계별 "방법"을 제공합니다. 메일 관리자가 AMP(Advanced Malware Protection) 또는 URL 필터링에 대해 MAR(Mailbox Auto Remediation)을 구성하거나 Cisco Secure Email and Web Manager 또는 Cisco Secure Gateway/Cloud Gateway에서 메시지 추적의 교정 작업을 사용하는 경우 계정 설정 및 연결된 계정 프로필을 구성해야 합니다.

사서함 자동 교정 프로세스 흐름

이메일 또는 URL의 첨부 파일(파일)은 사용자의 사서함에 도달한 후에도 언제든지 악성으로 평가될 수 있습니다. Cisco Secure Email의 AMP(Cisco Secure Malware Analytics를 통해)는 새로운 정보가 등장할 때 이러한 현상을 식별할 수 있으며 Cisco Secure Email로 회귀적 알림을 보냅니다. Cisco Talos는 AsyncOS 14.2 for Cisco Secure Email Cloud Gateway와 마찬가지로 URL 분석도 제공합니다.  조직에서 Microsoft 365를 사용하여 사서함을 관리하는 경우 이러한 위협 판정이 변경될 때 사용자 사서함의 메시지에 대해 자동 교정 작업을 수행하도록 Cisco Secure Email을 구성할 수 있습니다.

Cisco Secure Email은 Microsoft 365 사서함에 액세스할 수 있도록 Microsoft Azure Active Directory에 안전하게 직접 통신합니다.  예를 들어 첨부 파일이 있는 이메일이 게이트웨이를 통해 처리되고 AMP에서 스캔되는 경우 파일 첨부 파일(SHA256)은 파일 평판을 위해 AMP에 제공됩니다.  AMP 속성을 Clean(정상)으로 표시한 다음(그림 1, 5단계) 최종 수신자의 Microsoft 365 사서함으로 전달할 수 있습니다.  나중에 AMP 속성이 Malicious(악의적)로 변경되면 Cisco Malware Analytics는 특정 SHA256을 처리한 게이트웨이로 회귀적 판정 업데이트(8단계, 그림 1)를 보냅니다. 게이트웨이가 Malicious(구성된 경우)의 회귀적 판정 업데이트를 수신하면, 게이트웨이는 Forward(전달), Delete(삭제) 또는 Forward and Delete(전달 및 삭제) 작업 중 하나를 수행합니다.

그림 1: Cisco Secure Email의 3월(AMP의 경우)

    

이 설명서는 Microsoft 365 for Mailbox Auto Remediation에서만 Cisco Secure Email을 구성하는 방법에 대한 내용입니다.  게이트웨이에서 AMP(File Reputation and File Analysis) 및/또는 URL 필터링이 이미 구성되어 있어야 합니다.  파일 평판 및 파일 분석에 대한 자세한 내용은 배포한 AsyncOS 버전에 대한 사용 설명서를 참조하십시오.

    

사전 요구 사항

1. Microsoft 365 계정 구독(Microsoft 365 계정 구독에 Enterprise E3 또는 Enterprise E5 계정과 같은 Exchange에 대한 액세스가 포함되어 있는지 확인하십시오.)

2. Microsoft Azure 관리자 계정 및 http://portal.azure.com에 대한 액세스

3. Microsoft 365 및 Microsoft Azure AD 계정은 모두 활성 "user@domain.com" 전자 메일 주소에 제대로 연결되어 있으며 해당 전자 메일 주소를 통해 전자 메일을 보내고 받을 수 있습니다.

Microsoft Azure AD에 대한 Cisco Secure Email Gateway API 통신을 구성하기 위해 다음 값을 만듭니다.

• 클라이언트 ID
• 테넌트 ID
• 클라이언트 암호

참고: AsyncOS 14.0부터 계정 설정에서는 Microsoft Azure 앱 등록을 만들 때 클라이언트 암호를 사용하여 구성할 수 있습니다. 이것이 더 쉽고 선호하는 방법입니다.

   

선택 사항 - 클라이언트 암호를 사용하지 않는 경우 다음을 만들고 준비해야 합니다.

• 지문
• 개인 키(PEM 파일)

지문 및 개인 키 만들기는 이 가이드의 부록에서 다룹니다.

1. 활성 CER(공개 또는 개인) 인증서 및 PEM(인증서)에 서명하는 데 사용되는 개인 키 또는 CER(공개 인증서) 생성 기능 및 PEM(인증서)에 서명하는 데 사용되는 개인 키 저장 기능. Cisco는 이 문서에서 관리 기본 설정에 따라 이 작업을 수행하는 두 가지 방법을 제공합니다.
   1. 인증서: Unix/Linux/OS X(OpenSSL 사용)
   2. 인증서: Windows(PowerShell 사용)

2. Windows PowerShell 액세스 - 일반적으로 Windows 호스트 또는 서버에서 관리하거나 Unix/Linux를 통해 터미널 애플리케이션에 액세스합니다.

이러한 필수 값을 작성하려면 이 문서에 제공된 단계를 완료해야 합니다.

    

Cisco Secure Email에 사용할 Azure 앱 등록

애플리케이션 등록

Microsoft Azure 포털에 로그인 1. Azure Active Directory를 클릭합니다(그림 2) 2. App registrations(앱 등록)를 클릭합니다. 3. + New registration(신규 등록)을 클릭합니다. 4. "신청서 등록" 페이지에서 다음 각 목의 어느 하나에 해당하는 사항 a. 이름: Cisco Secure Email MAR(또는 선택한 이름) b. 지원되는 계정 유형: 이 조직 디렉토리의 계정만 해당(계정 이름) c. 리디렉션 URI: (선택 사항) [참고: 이 정보는 비워 두거나 https://www.cisco.com/sign-on을 사용하여 입력할 수 있습니다.] d. 페이지 하단에서 Register(등록)를 클릭합니다.

그림 2: Microsoft Azure 포털의 예

    

위 단계를 완료하면 애플리케이션이 표시됩니다.

    

그림 3: Microsoft Azure Active Directory 응용 프로그램 페이지

     

인증서 및 암호

AsyncOS 14.0 이상을 실행 중인 경우 클라이언트 암호를 사용하도록 Azure 앱을 구성하는 것이 좋습니다.  응용 프로그램 창의 관리 옵션에서 다음을 수행합니다.

1. 인증서 및 암호 선택

2. Client secrets(클라이언트 암호) 섹션에서 + New client secret(새 클라이언트 암호)을 클릭합니다

3. 이 클라이언트 암호에 대한 설명을 추가합니다(예: "Cisco Secure Email 교정").

4. 만료 기간을 선택합니다

5. 추가를 클릭합니다.

6. 생성된 값의 오른쪽으로 마우스를 가져가서 클립보드에 복사 아이콘을 클릭합니다

7. 이 값을 메모에 저장하고 "클라이언트 암호"로 기록합니다.

그림 4: Microsoft Azure 클라이언트 암호 만들기 예

    

참고: 활성 Microsoft Azure 세션을 종료하면 방금 생성한 클라이언트 암호의 값이 ***.  종료하기 전에 값을 기록하고 보호하지 않으면 클라이언트 암호를 다시 만들어야 일반 텍스트 출력을 볼 수 있습니다.

   

선택 사항 - 클라이언트 암호로 Azure 응용 프로그램을 구성하지 않는 경우 인증서를 사용하도록 Azure 앱을 구성하세요.  응용 프로그램 창의 관리 옵션에서 다음을 수행합니다.

1. 인증서 및 암호 선택
2. Upload certificate(인증서 업로드)를 클릭합니다.
3. CRT 파일 선택(이전에 만든 대로)
4. Add를 클릭합니다

     

API 권한

참고: AsyncOS 13.0 for Email Security부터 Microsoft Azure에서 Cisco Secure Email 커뮤니케이션에 대한 API 권한이 필요한 경우 Microsoft Exchange에서 Microsoft Graph로 변경되었습니다.  이미 MAR을 구성했고 기존 Cisco Secure Email 게이트웨이를 AsyncOS 13.0으로 업그레이드하는 경우 새 API 권한을 업데이트/추가하면 됩니다.  (이전 버전의 AsyncOS, 11.x 또는 12.x를 실행 중인 경우 계속하기 전에 부록 B를 참조하십시오.)

응용 프로그램 창의 관리 옵션에서 다음을 수행합니다.

1. API 권한 선택
2. + 권한 추가를 클릭합니다.
3. Microsoft Graph 선택
4. 응용 프로그램 사용 권한에 대한 아래 사용 권한을 선택하십시오.
   1. Mail(메일) > "Mail.Read(메일 읽기)"(모든 사서함에서 메일 읽기)
   2. Mail(메일) > "Mail.ReadWrite(Mail.ReadWrite)"(모든 사서함에서 메일 읽기 및 쓰기)
   3. Mail(메일) > "Mail.Send(메일 보내기)"(임의의 사용자로 메일 보내기)
   4. Directory(디렉토리) > "Directory.Read.All" (디렉토리 데이터 읽기) [*선택 사항: LDAP Connector/LDAP 동기화를 사용 중인 경우 enable(활성화).  그렇지 않은 경우, 이는 필수가 아닙니다.]
5. 선택 사항: Microsoft Graph가 기본적으로 "User.Read" 권한에 대해 활성화되어 있음을 확인할 수 있습니다. 이 권한을 구성된 상태로 두거나 Read를 클릭하고 Remove permission을 클릭하여 응용 프로그램과 연결된 API 권한에서 이 권한을 제거할 수 있습니다.
6. Add permissions(권한 추가)(또는 Update permissions(권한 업데이트)(Microsoft Graph가 이미 나열되어 있는 경우))를 클릭합니다
7. 마지막으로, 새 권한이 애플리케이션에 적용되도록 하려면 Grant admin consent for...를 클릭합니다
8. 다음과 같은 메시지가 표시되는 창 내 팝업이 표시됩니다.

"<Azure Name>의 모든 계정에 대해 요청된 권한에 대한 동의를 부여하시겠습니까? 이렇게 하면 이 응용 프로그램이 이미 아래 나열된 것과 일치해야 하는 기존 관리자 동의 레코드가 업데이트됩니다."

Yes(예)를 클릭합니다.

    

이때 녹색 성공 메시지가 표시되고 "Admin Consent Required(관리자 동의 필요)" 열에 Granted(승인됨)가 표시됩니다.

     

클라이언트 ID 및 테넌트 ID 가져오기

응용 프로그램 창의 관리 옵션에서 다음을 수행합니다.

1. Overview(개요)를 클릭합니다.
2. 애플리케이션(클라이언트) ID 오른쪽을 마우스로 가리키고 클립보드에 복사 아이콘을 클릭합니다
3. 이 값을 메모에 저장합니다. "클라이언트 ID"로 기록합니다.
4. 디렉토리(테넌트) ID 오른쪽으로 마우스를 가져가서 클립보드에 복사 아이콘을 클릭합니다
5. 이 값을 메모에 저장합니다. "테넌트 ID"로 기록합니다.

그림 5: Microsoft Azure... 클라이언트 ID, 테넌트 ID 예

     

Cisco Secure Email Gateway/Cloud 게이트웨이 구성

    

이때 다음 값을 준비하고 메모에 저장해야 합니다.

• 클라이언트 ID
• 테넌트 ID
• 클라이언트 암호

클라이언트 암호를 사용하지 않는 경우 선택 사항:

• 지문
• 개인 키(PEM 파일)

  

메모에서 생성된 값을 사용하고 Cisco Secure Email Gateway에서 계정 설정을 구성할 준비가 되었습니다.

    

계정 프로필 생성

1. 게이트웨이에 로그인
2. System Administration(시스템 관리) > Account Settings(계정 설정)로 이동합니다.
   • 참고: AsyncOS 13.x 이전 버전을 실행 중인 경우 이는 System Administration(시스템 관리) > Mailbox Settings(사서함 설정)가 됩니다
3. Enable(활성화)을 클릭합니다
4. Enable Account Settings(어카운트 설정 활성화) 확인란을 클릭하고 Submit(제출)을 클릭합니다
5. Create Account Profile(어카운트 프로필 생성)을 클릭합니다.
6. 프로필 이름 및 설명(여러 도메인이 있는 경우 계정을 고유하게 설명하는 항목) 제공
7. Microsoft 365 연결을 정의할 때 프로필 유형을 Office 365/하이브리드(그래프 API)로 둡니다
8. 클라이언트 ID 입력
9. 테넌트 ID 입력
10. Azure에서 구성한 대로 클라이언트 자격 증명에 대해 다음 중 하나를 수행합니다.
    1. Client Secret(클라이언트 암호)을 클릭하고 구성된 클라이언트 암호에 붙여넣습니다. 또는
    2. Client Certificate(클라이언트 인증서)를 클릭하고 Thumbprint(지문)를 입력한 다음 "Choose File(파일 선택)"을 클릭하여 PEM을 제공합니다. 
11. Submit(제출)을 클릭합니다.
12. UI 오른쪽 상단에서 Commit Changes(변경 사항 커밋)를 클릭합니다
13. 코멘트를 입력하고 Commit Changes(변경 사항 커밋)를 클릭하여 컨피그레이션 변경 사항을 완료합니다

            

연결 확인

다음 단계는 Cisco Secure Email Gateway에서 Microsoft Azure로의 API 연결을 확인하는 것입니다.

1. 동일한 Account Details(어카운트 세부사항) 페이지에서 Test Connection(연결 테스트)을 클릭합니다
2. Microsoft 365 계정에서 관리되는 도메인의 유효한 전자 메일 주소를 입력하십시오.
3. 연결 테스트를 클릭합니다.
4. 성공 메시지를 수신해야 합니다(그림 6).
5. Done(완료)을 클릭하여 완료합니다.

    

그림 6: 계정 프로필/연결 확인 예

     

6. Domain Mapping(도메인 매핑) 섹션에서 Create Domain Mapping(도메인 매핑 생성)을 클릭합니다

7. 방금 API 연결을 확인한 Microsoft 365 계정과 연결된 도메인 이름을 입력합니다

다음은 사서함 프로필을 매핑하는 데 사용할 수 있는 유효한 도메인 형식의 목록입니다.

- 도메인은 기본 도메인 매핑을 만들기 위해 모든 도메인과 일치하는 특수 키워드 'ALL'이 될 수 있습니다.

- 도메인 이름(예: 'example.com') - 이 도메인의 모든 주소와 일치시킵니다.

- '@.partial.example.com'과 같은 부분 도메인 이름 - 이 도메인으로 끝나는 모든 주소와 일치합니다.

- 쉼표로 구분된 도메인 목록을 사용하여 여러 도메인을 입력할 수 있습니다.

8. 제출을 클릭합니다

9. UI 오른쪽 상단에 있는 Commit Changes(변경사항 커밋)를 클릭합니다

10. 코멘트를 입력하고 변경사항 커밋을 눌러 구성 변경사항을 완료합니다

     

     

메일 정책에서 MAR(Mailbox Auto Remediation) for Advanced Malware Protection 사용

    

메일 정책에 대해 AMP 컨피그레이션에서 MAR을 활성화하려면 이 단계를 완료합니다.

    

1. Mail Policies(메일 정책) > Incoming Mail Policies(수신 메일 정책)로 이동합니다.
2. 구성할 정책 이름의 Advanced Malware Protection(AMP) 열에서 설정을 클릭합니다(예: 그림 7).

그림 7: MAR 활성화(수신 메일 정책)

3. 페이지 아래쪽으로 스크롤합니다.
4. Enable Mailbox Auto Remediation (MAR)(사서함 자동 교정 활성화(MAR)) 확인란을 클릭합니다
5. 3월에 수행할 다음 작업 중 하나를 선택합니다(예: 그림 8).
   • 다음으로 전달: <이메일 주소에 입력>
   • 삭제
   • 다음으로 전달: <이메일 주소에 입력> 및 삭제

그림 8: AMP용 MAR 컨피그레이션 예

    

6. Submit(제출)을 클릭합니다.
7. UI 오른쪽 상단에서 Commit Changes(변경 사항 커밋)를 클릭합니다
8. 코멘트를 입력하고 Commit Changes(변경 사항 커밋)를 클릭하여 컨피그레이션 변경 사항을 완료합니다

URL 필터링을 위한 MAR(Mailbox Auto Remediation) 활성화

    

AsyncOS 14.2 for Cisco Secure Email Cloud Gateway부터 URL 필터링에 URL 회귀적 판정 및 URL 교정이 포함됩니다.

1. Security Services(보안 서비스) > URL Filtering(URL 필터링)으로 이동합니다.
2. URL 필터링이 아직 구성되지 않은 경우 Enable(활성화)을 클릭합니다.
3. "URL 범주 및 평판 필터 사용" 확인란을 클릭합니다.
4. 기본 설정의 고급 설정
5. Submit(제출)을 클릭합니다.

URL 필터링은 다음과 유사해야 합니다.

그림 9: URL 필터링 사후 활성화 예

URL Retrospection with In URL Filtering(URL 필터링 포함)을 보려면 다음을 수행하거나 Cisco가 수행할 수 있도록 지원 케이스를 열어야 합니다.

esa1.hcxxyy-zz.iphmx.com> urlretroservice enable

URL Retro Service is enabled.

esa1.hcxxyy-zz.iphmx.com> websecurityconfig

URL Filtering is enabled.
No URL list used.
Web Interaction Tracking is enabled.
URL Retrospective service based Mail Auto Remediation is disabled.
URL Retrospective service status - Unavailable

Disable URL Filtering? [N]>

Do you wish to disable Web Interaction Tracking? [N]>

Do you wish to add URLs to the allowed list using a URL list? [N]>


Enable URL Retrospective service based Mail Auto Remediation to configure remediation actions.

Do you wish to enable Mailbox Auto Remediation action? [N]> y

URL Retrospective service based Mail Auto Remediation is enabled.

Please select a Mailbox Auto Remediation action:
1. Delete
2. Forward and Delete
3. Forward
[1]> 1

esa1.hcxxyy-zz.iphmx.com> commit

Please enter some comments describing your changes:
[]>

Do you want to save the current configuration for rollback? [Y]>

Changes committed: Tue Mar 29 19:43:48 2022 EDT

     

완료되면 URL Filtering(URL 필터링) 페이지에서 UI를 새로 고침하면 다음과 유사하게 표시됩니다.

그림 10: URL 필터링(AsyncOS 14.2 for Cisco Secure Email Cloud Gateway)

     

이제 URL 보호가 판정 점수가 변경될 때 교정 조치를 수행할 준비가 되었습니다.  자세한 내용은 AsyncOS 14.2 for Cisco Secure Email Cloud Gateway의 사용 설명서에서 악의적이거나 바람직하지 않은 URL로부터 보호를 참조하십시오.

    

컨피그레이션 완료!

    

이 시점에서 Cisco Secure Email은 새로운 정보를 사용할 수 있게 되면 지속적으로 새로운 위협을 평가하고 네트워크에 들어온 후 위협으로 확인된 파일에 대해 알려줄 준비가 되었습니다.

    

File Analysis(Cisco Secure Malware Analytics)에서 회귀적 판정이 생성되면 Email Security 관리자(구성된 경우)에게 정보 메시지가 전송됩니다.  예:

메일 정책에 대해 구성된 경우 사서함 자동 교정이 구성된 것으로 간주됩니다.

사서함 자동 교정 보고서 예

    

해결된 SHA256에 대한 보고는 Cisco Secure Email Gateway 및 Cisco Secure Email and Web Manager에서 모두 사용 가능한 Mailbox Auto Remediation 보고서에 포함됩니다.

    

그림 11: (레거시 UI) 사서함 자동 교정 보고서

     

그림 12: (NG UI) 사서함 자동 교정 보고서

사서함 자동 교정 로깅

    

Mailbox Auto Remediation에는 개별 로그 "mar"이 있습니다.  사서함 자동 교정 로그에는 Cisco Secure Email Gateway와 Microsoft Azure, Microsoft 365 간의 모든 통신 활동이 포함됩니다.

    

mar 로그의 예는 다음과 같습니다.

Mon May 27 02:24:28 2019 Info: Version: 12.1.0-087 SN: 420DE3B51AB744C7F092-9F0000000000
Mon May 27 02:24:28 2019 Info: Time offset from UTC: 18000 seconds
Fri May 31 01:11:53 2019 Info: Process ready for Mailbox Auto Remediation
Fri May 31 01:17:57 2019 Info: Trying to connect to Azure AD.
Fri May 31 01:17:57 2019 Info: Requesting token from Azure AD.
Fri May 31 01:17:58 2019 Info: Token request successful.
Fri May 31 01:17:58 2019 Info: The appliance is able to read the user's(robsherw@bce-demo.info) mailbox.
Fri May 31 04:41:54 2019 Info: Trying to perform the configured action on MID:312391 SHA256:de4dd03acda0a24d0f7e375875320538952f1fa30228d1f031ec00870ed39f62 Recipient:robsherw@bce-demo.info.
Fri May 31 04:41:55 2019 Info: Message containing attachment(s) for which verdict update was(were) available was not found in the recipient's (robsherw@bce-demo.info) mailbox.
Tue Jun  4 04:42:20 2019 Info: Trying to perform the configured action on MID:348938 SHA256:7d06fd224e0de7f26b48dc2daf7f099b3770080d98bd38c49ed049087c416c4b Recipient:robsherw@bce-demo.info.
Tue Jun  4 04:42:21 2019 Info: Message containing attachment(s) for which verdict update was(were) available was not found in the recipient's (robsherw@bce-demo.info) mailbox.

     

Cisco Secure Email Gateway 문제 해결

    

연결 상태 테스트에 대한 결과가 표시되지 않으면 Microsoft Azure AD에서 수행된 응용 프로그램 등록을 검토할 수 있습니다.

    

Cisco Secure Email 게이트웨이에서 MAR 로그를 'trace' 레벨로 설정하고 연결을 다시 테스트합니다.

    

연결에 실패한 경우 로그는 다음과 비슷하게 표시될 수 있습니다.

Thu Mar 30 16:08:49 2017 Info: Trying to connect to Azure AD.
Thu Mar 30 16:08:49 2017 Info: Requesting token from Azure AD.
Thu Mar 30 16:08:50 2017 Info: Error in requesting token: AADSTS70001: Application with identifier '445796d4-8e72-4d06-a72c-02eb47a4c59a' was not found in the directory ed437e13-ba50-479e-b40d-8affa4f7e1d7
 Trace ID: 4afd14f4-ca97-4b15-bba4-e9be19f30d00
 Correlation ID: f38e3388-729b-4068-b013-a08a5492f190
 Timestamp: 2017-03-30 20:08:50Z
Thu Mar 30 16:08:50 2017 Info: Error while requesting token AADSTS70001: Application with identifier '445796d4-8e72-4d06-a72c-02eb47a4c59a' was not found in the directory ed437e13-ba50-479e-b40d-8affa4f7e1d7
 Trace ID: 4afd14f4-ca97-4b15-bba4-e9be19f30d00
 Correlation ID: f38e3388-729b-4068-b013-a08a5492f190
 Timestamp: 2017-03-30 20:08:50Z

    

Azure AD에 있는 응용 프로그램의 로그에서 응용 프로그램 ID, 디렉터리 ID(테넌트 ID와 동일) 또는 기타 관련 식별자를 확인합니다. 값을 모를 경우 Azure AD 포털에서 응용 프로그램을 삭제하고 처음부터 다시 시작합니다.

    

성공적인 연결을 위해 로그는 다음과 유사해야 합니다.

Thu Mar 30 15:51:58 2017 Info: Trying to connect to Azure AD.
Thu Mar 30 15:51:58 2017 Info: Requesting token from Azure AD.
Thu Mar 30 15:51:58 2017 Trace: command session starting
Thu Mar 30 15:52:00 2017 Info: Token request successful.
Thu Mar 30 15:52:00 2017 Info: The appliance is able to read the user's(myuser@mydomain.onmicrosoft.com) mailbox.

     

Azure AD 문제 해결

        

참고: Cisco TAC 및 Cisco Support는 Microsoft Exchange, Microsoft Azure AD 또는 Office 365와 관련된 고객 측 문제를 해결할 수 없습니다.

    

Microsoft Azure AD와 관련된 고객 측 문제의 경우 Microsoft 지원을 이용해야 합니다.  Microsoft Azure 대시보드에서 "도움말 + 지원" 옵션을 참조하십시오.  대시보드에서 Microsoft 지원에 대한 직접 지원 요청을 열 수 있습니다.

     

부록 A

참고: Azure 응용 프로그램을 설정하는 데 클라이언트 암호를 사용하지 않는 경우에만 필요합니다.

     

공용 및 개인 인증서 및 키 쌍 구축

    

팁: 출력은 구성 단계의 뒷부분에 필요하므로 $base64Value, $base64Thumbprint 및 $keyid에 대해 로컬로 저장하십시오.  인증서의 .crt 및 관련 .pem을 컴퓨터에서 사용 가능한 로컬 폴더에 저장하십시오.

참고: 이미 인증서(x509 형식/표준) 및 개인 키가 있는 경우 이 섹션을 건너뜁니다.  CRT 및 PEM 파일은 다음 섹션에서 필요하므로 모두 보유하고 있어야 합니다!    

    

인증서: Unix/Linux(openssl 사용)

만들 값:

● 지문 ● 공개 인증서(CRT 파일) ● 개인 키(PEM 파일)

    

제공된 스크립트의 목적과 실행을 위해 Unix/Linux/OS X를 사용하는 관리자는 OpenSSL이 설치되어 있다고 가정합니다.

    

참고: OpenSSL 설치를 확인하려면 'which openssl' 및 'openssl version' 명령을 실행합니다. OpenSSL이 없는 경우 설치합니다.

    

도움이 필요하면 다음 문서를 참조하십시오. Cisco Secure Email용 Azure AD 구성 스크립트

    

호스트(UNIX/Linux/OS X): 

1. 터미널 응용 프로그램, 텍스트 편집기(또는 셸 스크립트를 작성하는 데 익숙함)에서 다음을 복사하여 스크립트를 만듭니다. https://raw.githubusercontent.com/robsherw/my_azure/master/my_azure.sh

2. 스크립트 붙여넣기
3. 스크립트를 실행 가능하도록 만드십시오! chmod u+x my_azure.sh 명령을 실행합니다.
4. 스크립트 실행: ./my_azure.sh

그림 13: my_azure.sh의 화면 출력

     

그림 2에서 볼 수 있듯이 스크립트는 Azure 앱 등록에 필요한 공용 인증서(CER 파일)를 빌드하고 호출합니다. 또한 스크립트는 Configuring Cisco Secure Email(Cisco 보안 이메일 구성) 섹션에서 사용할 ThumbprintandCertificate Private Key(PEM 파일)도 호출합니다. 

microsoft Azure에 응용 프로그램을 등록하는 데 필요한 값이 있습니다! 

     

[다음 섹션을 건너뛰십시오!  "Cisco Secure Email에 사용할 Azure 앱 등록"으로 진행하십시오.]

     

인증서: Windows(PowerShell 사용)

Windows를 사용하는 관리자의 경우 응용 프로그램을 활용하거나 자체 서명 인증서를 만드는 데 필요한 지식이 있어야 합니다.  이 인증서는 Microsoft Azure 응용 프로그램을 만들고 API 통신을 연결하는 데 사용됩니다.

만들 값:

● 지문 ● 공개 인증서(CRT 파일) ● 개인 키(PEM 파일)

     

이 문서에서 자체 서명 인증서를 만드는 예는 XCA(https://hohnstaedt.de/xca/,https://sourceforge.net/projects/xca/)를 사용하는 것입니다.

    

참고: XCA는 Mac, Linux 또는 Windows용으로 다운로드할 수 있습니다.

    

1. 인증서 및 키에 대한 데이터베이스를 만듭니다. a. 도구 모음에서 파일을 선택합니다. b. 새 데이터베이스 선택 c. 데이터베이스에 대한 암호를 만듭니다. (나중에 필요할 것이므로 기억하십시오!) 2. Certificates(인증서) 탭을 클릭한 다음 New Certificate(새 인증서)를 클릭합니다
3. Subject(제목) 탭을 클릭하고 다음을 입력합니다. a. 내부 이름 b. 국가 이름 c. 주/도 이름 d. 지역 이름 e. 조직 이름 f. OU(조직 구성 단위 이름) g. commonName(CN) h. 이메일 주소 4. 새 키 생성을 클릭합니다 5. 팝업창에서 제공된 정보를 확인합니다 (원하는 대로 변경): a. 이름 b. 키 유형: RSA c. 키 크기: 2048비트 d. Create(생성)를 클릭합니다 e. OK(확인)를 클릭하여 "Successfully created the RSA private key 'Name'(RSA 개인 키 '이름' 생성 성공)" 팝업을 승인합니다.	그림 14: XCA 사용(3-5단계)
6. Key usage(키 사용) 탭을 클릭하고 다음을 선택합니다. a. X509v3 Key Usage 아래에서:     디지털 서명, 키 암호화 b. X509v3 Extended Key Usage 아래에서:     이메일 보호	그림 15: XCA 사용(6단계)
7. 확인을 클릭하여 변경 사항을 인증서에 적용합니다 8. 확인을 클릭하여 "인증서 '이름'을 성공적으로 생성했습니다." 팝업을 승인합니다

    

다음으로, PowerShell 명령에서 사용하고 Cisco Secure Email 구성 단계에서 사용할 공용 인증서(CER 파일) 및 인증서 개인 키(PEM 파일)를 모두 내보냅니다.

    

1. 새로 생성한 인증서의 내부 이름을 클릭하여 선택합니다. 2. 내보내기를 클릭합니다 a. 액세스 편의를 위해 저장 디렉토리를 설정합니다(원하는 대로 변경). b. Export Format(내보내기 형식)이 PEM(.crt)으로 설정되었는지 확인합니다. c. 확인을 클릭합니다	그림 16: XCA 사용(CRT 내보내기)(1-2단계)
3. 개인 키 탭을 클릭합니다. 4. 새로 생성한 인증서의 내부 이름을 클릭하여 선택합니다. 5. 내보내기를 클릭합니다 a. 액세스 편의를 위해 저장 디렉토리를 설정합니다(원하는 대로 변경). b. Export Format(내보내기 형식)이 PEM private(.pem)으로 설정되었는지 확인합니다. c. 확인을 클릭합니다 6. XCA 종료 및 닫기	그림 17: XCA 사용(PEM 내보내기)(3-5단계)

    

    

마지막으로, 생성한 인증서를 가져와 Thumbprint(지문)를 추출합니다. 이는 Cisco Secure Email 구성에 필요합니다.

    

1. Windows PowerShell을 사용하여 다음을 실행합니다.

$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cer.Import("c:\Users\joe\Desktop\myCert.crt")
$bin = $cer.GetRawCertData()
$base64Value = [System.Convert]::ToBase64String($bin)
$bin = $cer.GetCertHash()
$base64Thumbprint = [System.Convert]::ToBase64String($bin)
$keyid = [System.Guid]::NewGuid().ToString()[Note: “c:\Users\joe\Desktop...” is the location on your PC where your CRT file is saved.]

    

2. 다음 단계에 대한 값을 가져오려면 파일에 저장하거나 클립보드에 복사합니다.

$base64Thumbprint | Out-File c:\Users\joe\Desktop\base64Thumbprint.txt
$base64Thumbprint

    

참고: "c:\Users\joe\Desktop..."은 출력을 저장하는 PC의 위치입니다.

    

PowerShell 명령을 실행할 때 필요한 출력은 다음과 같아야 합니다.

PS C:\Users\joe\Desktop> $base64Thumbprint
75fA1XJEJ4I1ZVFOB2xqkoCIh94=

    

보시다시피 PowerShell 명령은 Cisco Secure Email Gateway 컨피그레이션에 필요한 Thumbprint인 base64Thumbprint를 호출합니다. 

Azure 앱 등록에 필요한 공용 인증서(CER 파일) 만들기도 완료했습니다. Cisco Secure Email 구성 섹션에서 사용할 PEM(Certificate Private Key) 파일을 만들었습니다.

Microsoft Azure에 응용 프로그램을 등록하는 데 필요한 값이 있습니다!

     

[Cisco Secure Email에 사용할 Azure 앱 등록"으로 진행하세요.]

     

부록 B

참고: 게이트웨이에서 AsyncOS 11.x 또는 12.x for Email을 실행 중인 경우에만 필요합니다.

API 권한(AsyncOS 11.x, 12.x)

응용 프로그램 창의 관리 옵션...

1. API 권한 선택
2. + 권한 추가를 클릭합니다.
3. 아래로 스크롤하여 Supported legacy APIs(지원되는 레거시 API)로 이동한 후 Exchange를 선택합니다.
4. 위임된 권한에 대한 아래 권한을 선택하십시오.
   1. EWS > "EWS.AccessAsUser.All"(Exchange Web Services를 통해 사서함에 로그인한 사용자로 액세스)
   2. Mail(메일) > "Mail.Read(메일 읽기)"(사용자 메일 읽기)
   3. Mail > "Mail.ReadWrite" (사용자 메일 읽기 및 쓰기)
   4. Mail(메일) > "Mail.Send(메일 보내기)"(사용자로 메일 보내기)
5. 창의 맨 위로 스크롤합니다.
6. 응용 프로그램 사용 권한에 대한 아래 사용 권한을 선택하십시오.
   1. "full_access_as_app"(모든 사서함에 대한 전체 액세스 권한과 함께 Exchange 웹 서비스 사용)
   2. Mail(메일) > "Mail.Read(메일 읽기)"(사용자 메일 읽기)
   3. Mail > "Mail.ReadWrite" (사용자 메일 읽기 및 쓰기)
   4. Mail(메일) > "Mail.Send(메일 보내기)"(사용자로 메일 보내기)
7. 선택 사항: Microsoft Graph가 기본적으로 "User.Read" 권한에 대해 활성화되어 있음을 확인할 수 있습니다. 이 권한을 구성된 상태로 두거나 Read를 클릭하고 Remove permission을 클릭하여 응용 프로그램과 연결된 API 권한에서 이 권한을 제거할 수 있습니다.
8. Add permissions(권한 추가)(또는 Update permissions(권한 업데이트)(Microsoft Graph가 이미 나열되어 있는 경우))를 클릭합니다
9. 마지막으로, 새 권한이 애플리케이션에 적용되도록 하려면 Grant admin consent for...를 클릭합니다
10. 다음과 같은 메시지가 표시되는 창 내 팝업이 표시됩니다.

"<Azure Name>의 모든 계정에 대해 요청된 권한에 대한 동의를 부여하시겠습니까? 이렇게 하면 이 응용 프로그램이 이미 아래 나열된 것과 일치해야 하는 기존 관리자 동의 레코드가 업데이트됩니다."

Yes(예)를 클릭합니다.

    

이때 녹색 성공 메시지가 표시되고 "Admin Consent Required"(관리자 동의 필요) 열이 Granted(부여됨)로 표시됩니다.

    

그림 18: Microsoft Azure 앱 등록(API 권한 필요)

     

[Cisco Secure Email에 사용할 Azure 앱 등록"으로 진행하세요.]

     

     

관련 정보

• Cisco Email Security Appliance - 제품 지원
• Cisco Email Security Appliance - 릴리스 정보
• Cisco Email Security Appliance - 최종 사용자 가이드