Microsoft Azure(Microsoft 365) API用のCisco Secure Email Account設定の設定方法

概要

このドキュメントでは、Microsoft Azure(Azure Active Directory)に新しいアプリケーションを登録して、必要なクライアントID、テナントID、クライアント資格情報を生成し、Cisco Secure Email Gatewayまたはクラウドゲートウェイのアカウント設定を構成する手順を説明します。メール管理者がCisco Secure Email and Web ManagerまたはCisco Secure Gateway/Cloud Gateway上で高度なマルウェア防御(AMP)またはURLフィルタリング用にメールボックス自動修復(MAR)を設定したり、メッセージ追跡からの修復アクションを利用したりする場合、アカウント設定および関連するアカウントプロファイルの設定が必要です。

メールボックスの自動修復のプロセスフロー

電子メールまたは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 Azure Active Directoryと安全かつ直接通信して、Microsoft 365メールボックスにアクセスします。  たとえば、添付ファイルを含む電子メールがゲートウェイ経由で処理され、AMPによってスキャンされる場合、ファイルレピュテーションのために添付ファイル(SHA256)がAMPに提供されます。  AMPディスポジションは、クリーンとしてマークし（ステップ5、図1）、エンド受信者のMicrosoft 365メールボックスに配信できます。  その後、AMPの処理がMaliciousに変更され、Cisco Malware Analyticsは、特定のSHA256を処理したゲートウェイに対してレトロスペクティブな判定アップデート（ステップ8、図1）を送信します(ステップ8、図1)。  ゲートウェイは、Malicious（設定されている場合）のレトロスペクティブな判定アップデートを受信すると、次のいずれかのMailbox Auto Remediation(MAR)アクションを実行します。[転送]、[削除]、または[転送と削除]。

図 1：Cisco Secure EmailのMAR（AMP用）

    

このガイドでは、Microsoft 365を使用したCisco Secure Emailのメールボックス自動修復専用の設定方法について説明します。  ゲートウェイでAMP（ファイルレピュテーションとファイル分析）および/または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以降では、[Account Settings] を使用すると、Microsoft Azureアプリ登録の作成時にクライアントシークレットを使用して設定できます。これは簡単で推奨される方法です。

   

オプション：クライアントシークレットを使用しない場合は、次のものを作成し、準備しておく必要があります。

• 拇印
• 秘密キー（PEMファイル）

拇印と秘密キーの作成については、このガイドの付録で説明します。

1. アクティブなパブリック（またはプライベート）証明書(CER)と、証明書(PEM)の署名に使用される秘密キー、またはパブリック証明書(CER)を作成する機能と、証明書(PEM)の署名に使用される秘密キーを保存する機能。このドキュメントでは、管理上の設定に基づいて、次の2つの方法を提供しています。
   1. 証明書:Unix/Linux/OS X（OpenSSLを使用）
   2. 証明書:Windows （PowerShellを使用）

2. Windows PowerShellへのアクセス。通常はWindowsホストまたはサーバから管理されるか、Unix/Linux経由でターミナルアプリケーションにアクセスします。

これらの必須の値を設定するには、このドキュメントで説明する手順を実行する必要があります。

    

Cisco Secure Emailで使用するAzureアプリの登録

申請登録

Microsoft Azure Portalにログインします 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アプリを構成することをお勧めします。  アプリケーションペインの[Manage options:

1. [Certificates & secrets]を選択します。

2. [Client secrets] セクションで、[New client secret] をクリックします

3.このクライアントシークレットの目的を識別するための説明を追加します。たとえば、「Cisco Secure Email remediation」

4.有効期限を選択します

5. [Add] をクリックします

6.生成された値の右側にマウスを置き、[Copy to Clipboard] アイコンをクリックします

7.この値をメモに保存し、「Client secret」としてメモします。

図 4：Microsoft Azureクライアントシークレットの作成の例

    

注：アクティブなMicrosoft Azureセッションを終了すると、先ほど生成したクライアントシークレットの値が***の値から削除されます。  終了する前に値を記録して保護しない場合は、クリアテキスト出力を表示するためにクライアントシークレットを再作成する必要があります。

   

オプション：クライアントシークレットを使用してAzureアプリケーションを構成しない場合は、証明書を使用するようにAzureアプリケーションを構成してください。  アプリケーションペインの[Manage options:

1. [Certificates & secrets] を選択します。
2. [Upload certificate] をクリックします
3. CRTファイルを選択します（前の手順で作成）。
4. [Add] をクリックします。

     

API権限

注：AsyncOS 13.0 for Email Security以降では、Microsoft AzureからCisco Secure Email CommunicationへのAPIアクセス許可の要件が、Microsoft ExchangeからMicrosoft Graphへの使用から変更されました。MARをすでに設定していて、既存のCisco Secure Email GatewayをAsyncOS 13.0にアップグレードする場合は、新しいAPIアクセス許可を更新または追加できます。  (古いバージョンのAsyncOS（11.xまたは12.x）を実行している場合は、続行する前に付録Bを参照してください)。

アプリケーションペインの[Manage options:

1. API権限の選択
2. [+ Add a permission] をクリックします。
3. Microsoft Graphの選択
4. [Application permissions] で次の権限を選択します。
   1. Mail > "Mail.Read" （すべてのメールボックスのメールを読む）
   2. [Mail] > [Mail.ReadWrite]（すべてのメールボックスのメールの読み書き）
   3. [Mail] > [Mail.Send]（任意のユーザとしてメールを送信）
   4. Directory > "Directory.Read.All" （ディレクトリ・データの読み取り） [*オプション：LDAPコネクタ/LDAP同期を使用している場合は、を有効にします。  そうでない場合、これは必要ありません。]
5. オプション：Microsoft Graphでは、デフォルトで「User.Read」権限が有効になっています。この権限は設定したままにしておくか、または[Read] をクリックして[Remove permission] をクリックし、アプリケーションに関連付けられたAPI権限からこの権限を削除します。
6. [Add permissions] をクリックします(Microsoft Graphがすでにリストされている場合は[Update permissions] をクリックします)。
7. 最後に、Grant admin consent for... アプリケーションに新しい権限が適用されていることを確認する
8. 次の確認を求めるポップアップウィンドウが表示されます。

"<Azure Name>のすべてのアカウントに対して要求されたアクセス許可の同意を付与しますか？これにより、このアプリケーションが既に持っている既存の管理者同意レコードが、以下にリストされているものと一致するように更新されます。

[Yes] をクリックします

    

この時点で、成功を示す緑色のメッセージが表示され、[Admin Consent Required]列に[Granted]と表示されます。

     

クライアントIDとテナントIDの取得

アプリケーションペインの[Manage options:

1. [Overview] をクリックします
2. アプリケーション（クライアント）IDの右側にマウスを置き、[Copy to Clipboard] アイコンをクリックします
3. この値をメモに保存し、「クライアントID」としてメモします。
4. ディレクトリ（テナント）IDの右側にマウスを移動し、[Copy to Clipboard] アイコンをクリックします
5. この値をメモに保存し、「テナントID」としてメモします。

図 5：Microsoft Azure...クライアントID、テナントIDの例

     

Cisco Secure Email Gateway/クラウドゲートウェイの設定

    

この時点で、次の値を準備してノートに保存する必要があります。

• クライアント 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 / Hybrid (Graph API)のままにしておきます
8. クライアントIDを入力
9. テナントIDを入力します
10. Azureで構成したように、クライアント資格情報に対して次のいずれかを実行します：
    1. [Client Secret] をクリックし、設定したクライアントシークレットを貼り付けます。または、...
    2. [Client Certificate] をクリックし、拇印を入力し、[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. [Test Connection] をクリックします
4. 成功メッセージが表示されます（図6）
5. [Done] をクリックして終了します

    

図 6：アカウントプロファイル/接続チェックの例

     

6. [Domain Mapping] セクションで、[Create Domain Mapping] をクリックします

7. API接続を検証したMicrosoft 365アカウントに関連付けられているドメイン名を入力します

メールボックスプロファイルのマッピングに使用できる有効なドメイン形式の一覧を次に示します。

– ドメインは、デフォルトドメインマッピングを作成するためにすべてのドメインに一致する特別なキーワード「ALL」にすることができます。

- 「example.com」などのドメイン名：このドメインのアドレスに一致します。

- '@.partial.example.com'などの部分的なドメイン名 – このドメインで終わるアドレスに一致します

– 複数のドメインは、カンマで区切られたドメインのリストを使用して入力できます。

8. [Submit] をクリックします

9. UIの右上にある[Commit Changes] をクリックします

10.コメントを入力し、[Commit Changes] をクリックして設定の変更を完了します

     

     

メールポリシーで高度なマルウェア防御のためのメールボックス自動修復(MAR)を有効にする

    

メールポリシーのAMP設定でMARを有効にするには、次の手順を実行します。

    

1. [Mail Policies] > [Incoming Mail Policies] に移動します。
2. 設定するポリシー名の[Advanced Malware Protection]列の設定をクリックします（図7など）。

図 7：MAR （受信メールポリシー）を有効にする

3. ページの一番下までスクロールします
4. [Enable Mailbox Auto Remediation (MAR)(メールボックス自動修復を有効にする(MAR))]のチェックボックスをオンにします
5. MARに対して実行する次のアクションのいずれかを選択します（例：図8）。
   • 転送先：<電子メールアドレスを入力>
   • [削除（Delete）]
   • 転送先：<電子メールアドレスを入力>と削除

図 8：AMPのMARを有効にする設定例

    

6. [Submit] をクリックします。
7. UIの右上にある[Commit Changes] をクリックします
8. コメントを入力し、[Commit Changes] をクリックして設定の変更を完了します

URLフィルタリングのメールボックス自動修復(MAR)を有効にする

    

AsyncOS 14.2 for Cisco Secure Email Cloud Gateway以降、URLフィルタリングにURL Retrospective VerdictおよびURL Remediationが含まれるようになりました。

1. [Security Services] > [URL Filtering] に移動します。
2. URLフィルタリングが設定されていない場合は、[Enable] をクリックします
3. [Enable URL Category and Reputation Filters]のチェックボックスをクリックします。
4. デフォルト設定での[Advanced Settings]
5. [Submit] をクリックします。

URLフィルタリングは次のようになります。

図 9：イネーブル後のURLフィルタリングの例

URLフィルタリングを含むURLレトロスペクションを表示するには、次の手順を実行するか、シスコが実行するサポートケースをオープンします。

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]ページのUIを更新すると、次のようなメッセージが表示されます。

図 10：URLフィルタリング（Cisco Secure Email Cloud Gateway向けAsyncOS 14.2）

     

評決のスコアが変更されたときにURL保護が是正措置を実行する準備ができました。  詳細については、『AsyncOS 14.2 for Cisco Secure Email Cloud Gatewayユーザガイド』の「悪意のあるURLや望ましくないURLからの保護」を参照してください。

    

設定が完了しました。

    

現時点では、Cisco Secure Emailは、新しい情報が利用可能になったときに新たな脅威を継続的に評価し、脅威であると判断されたファイルがネットワークに侵入した後に通知する準備が整っています。

    

ファイル分析(Cisco Secure Malware Analytics)からレトロスペクティブ判定が生成されると、情報メッセージがEメールセキュリティ管理者（設定されている場合）に送信されます。  例：

メールボックスの自動修復は、メールポリシーに対して設定されている場合、設定されたとおりに実行されます。

メールボックス自動修復レポートの例

    

修復されたSHA256のレポートは、Cisco Secure Email GatewayとCisco Secure Email and Web Managerの両方で利用可能なMailbox Auto Remediationレポートに含まれます。

    

図 11：（レガシーUI）メールボックス自動修復レポート

     

図 12：(NG UI)メールボックス自動修復レポート

メールボックスの自動修復ログ

    

メールボックスの自動修復には、個別のログ「mar」があります。  Mailbox Auto Remediationログには、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 Gatewayから、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と同じ）、またはその他の関連付けられた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およびシスコサポートは、Microsoft Exchange、Microsoft Azure AD、またはOffice 365に関するお客様側の問題のトラブルシューティングを行う資格がありません。

    

Microsoft Azure ADのカスタマー側の問題については、Microsoftサポートに連絡する必要があります。 Microsoft Azure Dashboardの[ヘルプ+サポート]オプションを参照してください。 ダッシュボードから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が存在しない場合はインストールします。

    

サポートについては、次のドキュメントを参照してください。Azure AD Configuration Script for Cisco Secure Email

    

ホストから(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 Appの登録に必要な公開証明書（CERファイル）を構築して呼び出します。また、スクリプトは拇印と証明書秘密キー（PEMファイル）「Cisco Secure Emailの設定」の項でを使用します。 

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.ツールバーから[File] を選択します b.[New Database] を選択します。 c.データベースのパスワードを作成します （後の手順で必要になるので、覚えておいてください）。 2. [Certificates]タブをクリックし、[New Certificate] をクリックします
3. 「件名」タブをクリックし、次の項目を入力します。 a.内部名 b.countryName c.stateOrProvinceName d.localityName e.organizationName f. organizationalUnitName (OU) g.commonName(CN) h.emailAddress 4. [Generate a New Key] をクリックします。 5.ポップアップで、表示された情報を確認します （必要に応じて変更）: a.[名前(Name)] b.キータイプ：RSA c.キーサイズ：2048 ビット d.[Create]をクリックします。 e.[OK] をクリックして、「Successfully created the RSA private key 'Name'」ポップアップを確認します	図 14：XCAの使用（ステップ3 ～ 5）
6. [キー使用法]タブをクリックし、次の項目を選択します。 a.[X509v3 Key Usage]で、次の手順を実行します。     デジタル署名、キー暗号化 b.[X509v3 Extended Key Usage]で、次の手順を実行します。     電子メール保護	図 15：XCAの使用（ステップ6）
7. [OK] をクリックして、証明書に変更を適用します 8. [OK] をクリックして、[Successfully created the certificate 'Name']ポップアップを確認します

    

次に、公開証明書（CERファイル）と証明書秘密キー（PEMファイル）の両方をエクスポートして、次のPowerShellコマンドで使用し、「Cisco Secure Emailの設定」の手順で使用できるようにします。

    

1.をクリックし、新しく作成した証明書の[Internal Name]を強調表示します。 2. [Export] をクリックします a.アクセスを容易にするために保存ディレクトリを設定する（必要に応じて変更） b.[Export Format]が[PEM (.crt)] に設定されていることを確認します。 c. [OK]をクリックします。	図 16：XCAの使用(export CRT)（ステップ1 ～ 2）
3. [Private Keys] タブをクリックします 4.をクリックし、新しく作成した証明書の[Internal Name]を強調表示します。 5. [Export] をクリックします a.アクセスを容易にするために保存ディレクトリを設定する（必要に応じて変更） b.[Export Format]が[PEM private (.pem)] に設定されていることを確認します。 c. [OK]をクリックします。 6. XCAを終了して閉じます	図 17：XCAの使用（エクスポートPEM）（ステップ3 ～ 5）

    

    

最後に、作成した証明書を取得し、Cisco Secure Emailの設定に必要なThumbprintを抽出します。

    

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コマンドは、base64Thumbprintを呼び出します。これは、Cisco Secure Email Gatewayの設定に必要なThumbprintです。 

Azureアプリの登録に必要な公開証明書（CERファイル）の作成も完了しました。「Cisco Secure Emailの設定」セクションで使用する証明書秘密キー（PEMファイル）を作成しました。

Microsoft Azureにアプリケーションを登録するために必要な値があります！

     

[「Cisco Secure Emailで使用するAzureアプリの登録」に進んでください]

     

付録 B

注：これは、ゲートウェイでAsyncOS 11.xまたは12.x for Emailを実行している場合にのみ必要です。

API権限(AsyncOS 11.x、12.x)

アプリケーションペインの管理オプション…

1. API権限の選択
2. [+ Add a permission] をクリックします。
3. [Supported legacy APIs] までスクロールダウンして、[Exchange] を選択します
4. 委任されたアクセス許可で次のアクセス許可を選択してください：
   1. EWS > "EWS.AccessAsUser.All" （Exchange Webサービス経由でサインインしたユーザーとしてメールボックスにアクセスします）
   2. Mail > "Mail.Read" （ユーザメールを読む）
   3. [Mail] > [Mail.ReadWrite]（ユーザメールの読み書き）
   4. [Mail] > [Mail.Send]（ユーザとしてメールを送信）
5. ペインの上部までスクロールします…
6. アプリケーション権限に対して次の権限を選択します。
   1. 「full_access_as_app」（すべてのメールボックスへのフルアクセスを持つExchange Webサービスを使用）
   2. Mail > "Mail.Read" （ユーザメールを読む）
   3. [Mail] > [Mail.ReadWrite]（ユーザメールの読み書き）
   4. [Mail] > [Mail.Send]（ユーザとしてメールを送信）
7. オプション：Microsoft Graphでは、デフォルトで「User.Read」権限が有効になっています。この権限は設定したままにしておくか、または[Read] をクリックして[Remove permission] をクリックし、アプリケーションに関連付けられたAPI権限からこの権限を削除します。
8. [Add permissions] をクリックします(Microsoft Graphがすでにリストされている場合は[Update permissions] をクリックします)。
9. 最後に、Grant admin consent for... アプリケーションに新しい権限が適用されていることを確認する
10. 次の確認を求めるポップアップウィンドウが表示されます。

"<Azure Name>のすべてのアカウントに対して要求されたアクセス許可の同意を付与しますか？これにより、このアプリケーションが既に持っている既存の管理者同意レコードが、以下にリストされているものと一致するように更新されます。

[Yes] をクリックします

    

この時点で、成功を示すメッセージが緑色になり、[Admin Consent Required]列に[Granted]と表示されます。次に例を示します。

    

図 18：Microsoft Azureアプリの登録（APIアクセス許可が必要）

     

[「Cisco Secure Emailで使用するAzureアプリの登録」に進んでください]

     

     

関連情報

• Cisco Eメールセキュリティアプライアンス – 製品サポート
• Cisco Eメールセキュリティアプライアンス – リリースノート
• Cisco Eメールセキュリティアプライアンス – エンドユーザガイド