Office 365 の操作可能なメッセージのセキュリティ要件

[アーティクル]
04/29/2024

重要

グローバル スコープを持つ新しいアクション可能メッセージプロバイダーのオンボードは、サービスのアップグレードにより、2024 年 6 月 30 日まで一時的に一時停止されます。既存 のグローバル スコーププロバイダーと組織および テスト スコーププロバイダーのオンボードは影響を受けません。詳細については、「アクション可能なメッセージについてよく寄せられる質問」を参照してください。

操作可能なメールのセキュリティ保護はシンプルで簡単です。エンドツーエンドエクスペリエンスには 2 つのフェーズがあり、Office 365 で操作可能なメッセージをサポートしている場合に、サービスにセキュリティ要件が適用されます。フェーズと対応する要件は次のとおりです。

送信フェーズ:操作可能なメッセージを送信するためのサービスの前提条件は次のとおりです。
- 操作可能なメールを使用している場合は、[送信者の認証] を有効にする必要があります。これは、コネクタメッセージには適用されないことにご注意ください。
- サービスは Microsoft に登録されている必要があります。
- アクション URL は HTTPS をサポートする必要があります。
アクションの処理フェーズ:アクションを処理する場合、サービスで次の操作を実行する必要があります。
- HTTP POST 要求のヘッダーに含まれるベアラートークン (JSON Web トークン) を検証します。検証は、Microsoft によって提供されるサンプルライブラリを活用して行うこともできます。
- サービスの限定目的トークンをターゲット URL の一部として含めます。これは、サービス URL をユーザーが意図した要求 & 関連付けるためにサービスで使用できます。これは省略可能ですが、強くお勧めします。

送信者の認証

Office 365 では、メール経由で操作可能なメッセージを処理するのに、送信者の認証が必要です。操作可能なメッセージのメールは、DomainKeys Identified Mail (DKIM) と Sender Policy Framework (SPF) を実装するサーバーから送信するか、署名済みカードを実装する必要があります。

DKIM と SPF で十分なシナリオもありますが、メールが外部のプロバイダー経由で送信される一部の状況ではこのソリューションが機能せず、機能が拡張された操作可能なメッセージを受信者が受け取れなくなる場合があります。この理由から、いつでも署名済みカードを実装するようにお勧めします。署名済みカードは、どのような場合でも機能するだけでなく、DNS レコードに依存しないので基本的に一層安全です。

DKIM と SPF の実装

DKIM と SPF は、SMTP 経由でメールを送信するときに送信者の身元を証明するための業界標準方式です。多くの企業は、送信するメールをセキュリティ保護するため、既にこれらの標準方式を実装しています。 SPF/DKIM とその実装方法の詳細については、以下を参照してください。

署名済みカードのペイロード

メール経由で送信された操作可能なメッセージは、代替の認証方法をサポートしています。その方法とは、RSA キーまたは X509 証明書を使用してカードペイロードに署名することです。この方法は、次のようなシナリオで必要です。

送信者の設定、または受信者テナントで Office 365 サービスの前にカスタムセキュリティサービスが設定されたことにより引き起こされた SPF/DKIM の障害。
操作可能なメッセージを複数のメールアカウントから送信する必要があります。

署名付きカードを使用するには、公開キーをメール開発者ダッシュボードに登録し、対応する秘密キーを使用してカードに署名する必要があります。

SignedCard

署名済みの操作可能なメッセージカードは、メール経由で送信する際に使用できます。次の書式を使用して、メールの HTML 本文に署名済みカードを含めます。このペイロードは、HTML 本文の末尾に追加される Microdata 形式でシリアル化します。

<section itemscope itemtype="http://schema.org/SignedAdaptiveCard">
    <meta itemprop="@context" content="http://schema.org/extensions" />
    <meta itemprop="@type" content="SignedAdaptiveCard" />
    <div itemprop="signedAdaptiveCard" style="mso-hide:all;display:none;max-height:0px;overflow:hidden;">[SignedCardPayload]</div>
</section>

注: 従来の MessageCard エンティティを使用することを希望するパートナーは、SignedAdaptiveCard の代わりに SignedMessageCard エンティティを作成できます。

SignedCardPayload

SignedCardPayload は、JSON Web Signature (JWS) 標準でエンコードされた文字列です。 RFC7515 は JWS を記述し、RFC7519 は JSON Web トークン (JWT) を記述します。 JWT ではクレームを必要としないため、JWS Signature の構築で JWT ライブラリを使用できます。

注: 実際には、"JWT" という用語は同じ意味で使用できます。ただし、ここでは "JWS" という用語を使用します。

SignedCardPayload の例を示します。エンコードされたアダプティブカードが、JWS の仕様に従って [ヘッダー].[ペイロード].[署名] の形式で表示されます。

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZW5kZXIiOiJzZXJ2aWNlLWFjY291bnRAY29udG9zby5jb20iLCJvcmlnaW5hdG9yIjoiNjVjNjgwZWYtMzZhNi00YTFiLWI4NGMtYTdiNWM2MTk4NzkyIiwicmVjaXBpZW50c1NlcmlhbGl6ZWQiOiJbXCJqb2huQGNvbnRvc28uY29tXCIsXCJqYW5lQGNvbnRvc28uY29tXCJdIiwiYWRhcHRpdmVDYXJkU2VyaWFsaXplZCI6IntcIiRzY2hlbWFcIjpcImh0dHA6Ly9hZGFwdGl2ZWNhcmRzLmlvL3NjaGVtYXMvYWRhcHRpdmUtY2FyZC5qc29uXCIsXCJ0eXBlXCI6XCJBZGFwdGl2ZUNhcmRcIixcInZlcnNpb25cIjpcIjEuMFwiLFwiYm9keVwiOlt7XCJzaXplXCI6XCJsYXJnZVwiLFwidGV4dFwiOlwiSGVsbG8gQWN0aW9uYWJsZSBtZXNzYWdlXCIsXCJ3cmFwXCI6dHJ1ZSxcInR5cGVcIjpcIlRleHRCbG9ja1wifV0sXCJhY3Rpb25zXCI6W3tcInR5cGVcIjpcIkFjdGlvbi5JbnZva2VBZGRJbkNvbW1hbmRcIixcInRpdGxlXCI6XCJPcGVuIEFjdGlvbmFibGUgTWVzc2FnZXMgRGVidWdnZXJcIixcImFkZEluSWRcIjpcIjNkMTQwOGY2LWFmYjMtNGJhZi1hYWNkLTU1Y2Q4NjdiYjBmYVwiLFwiZGVza3RvcENvbW1hbmRJZFwiOlwiYW1EZWJ1Z2dlck9wZW5QYW5lQnV0dG9uXCJ9XX0iLCJpYXQiOjE1NDUzNDgxNTN9.BP9mK33S1VZyjtWZd-lNTTjvueyeeoitygw9bl17TeQFTUDh9Kg5cB3fB7BeZYQs6IiWa1VGRdiiR4q9EkAB1qDsmIcJnw6aYwDUZ1KY4lNoYgQCH__FxEPHViGidNGtq1vAC6ODw0oIfaTUWTa5cF5MfiRBIhpQ530mbRNnA0QSrBYtyB54EDJxjBF1vNSKOeVHAl2d4gqcGxsytQA0PA7XMbrZ8B7fEU2uNjSiLQpoh6A1tevpla2C7W6h-Wekgsmjpw2YToAOX67VZ1TcS5oZAHmjv2RhqsfX5DlN-ZsTRErU4Hs5d92NY9ijJPDunSLyUFNCw7HLNPFqqPmZsw

上記の JWS のヘッダーは次のとおりです。

{
  "alg": "RS256",
  "typ": "JWT"
}

上記の JWS のペイロードは次のとおりです。

{
  "sender": "service-account@contoso.com",
  "originator": "65c680ef-36a6-4a1b-b84c-a7b5c6198792",
  "recipientsSerialized": "[\"john@contoso.com\",\"jane@contoso.com\"]",
  "adaptiveCardSerialized": "{\"$schema\":\"http://adaptivecards.io/schemas/adaptive-card.json\",\"type\":\"AdaptiveCard\",\"version\":\"1.0\",\"body\":[{\"size\":\"large\",\"text\":\"Hello Actionable message\",\"wrap\":true,\"type\":\"TextBlock\"}],\"actions\":[{\"type\":\"Action.InvokeAddInCommand\",\"title\":\"Open Actionable Messages Debugger\",\"addInId\":\"3d1408f6-afb3-4baf-aacd-55cd867bb0fa\",\"desktopCommandId\":\"amDebuggerOpenPaneButton\"}]}",
  "iat": 1545348153
}

必要なクレーム

クレーム	説明
`originator`	オンボーディング中に Microsoft によって提供される ID に設定する必要があります。
`iat`	ペイロードが署名された時刻。
`sender`	この操作可能なメッセージを送信するために使用されるメールアドレス。
`recipientsSerialized`	文字列に変換されたメールの受信者のリスト。これには、メールのすべての宛先/CC の受信者を含める必要があります。
`adaptiveCardSerialized`	文字列に変換されたアダプティブカード。

署名済みカードを生成するサンプルコード:

要求が Microsoft からのものであることの確認

Microsoft からのすべてのアクション要求には、HTTP Authorization ヘッダーにベアラートークンがあります。このトークンは、Microsoft によって署名された JSON Web トークン (JWT) トークンであり、関連する要求を処理するサービスによって検証されることを強くお勧めする重要な要求が含まれています。

クレームの名前	値
`aud`	ターゲットサービスのベース URL (例: `https://api.contoso.com`)
`iss`	トークンの発行者。これは `https://substrate.office.com/sts/` にする必要があります
`sub`	アクションを実行したユーザーの ID。メールで送信された操作可能なメッセージの場合、`sub` はユーザーのメールアドレスになります。コネクタの場合、`sub` はアクションを実行したユーザーの objectID になります。
`sender`	アクションを含むメッセージの送信者の ID。この値は、操作可能なメッセージがメールで送信された場合にのみ存在します。コネクタを介して送信される操作可能なメッセージには、ベアラートークンにこのクレームが含まれていません。

通常、サービスは次の検証を行います。

トークンが Microsoft によって署名されている。 OpenID メタデータは https://substrate.office.com/sts/common/.well-known/openid-configuration にあり、署名キーに関する情報が含まれています。
aud クレームがサービスのベース URL に対応している。

上記の検証がすべて完了すると、サービスは、sender と sub のクレームを信頼して、アクションを実行している送信者とユーザーの ID にできます。サービスは、と sub 要求が、想定している送信者とユーザーと一致することをsender検証できます。

以下に示す Microsoft コードサンプルを参照してください。上記の検証を JWT トークンで行う方法が示されます。

アクション承認ヘッダー

操作可能なメッセージで Authorization ヘッダーを使うと、対象のエンドポイントに対する既存の認証または承認メカニズムに干渉する可能性があります。この場合、開発者はアクションの Authorization プロパティでヘッダーを空の文字列にheadersAction.Http設定できます。そうすると操作可能なメッセージは、Authorization ヘッダーを使う代わりに Action-Authorization ヘッダー経由で同じベアラートークンを送信します。

ヒント

Azure Logic App サービスは、もし Authorization ヘッダーに操作可能なメッセージで設定されたベアラートークンが含まれる場合、HTTP 401 Unauthorized を返します。

アクション承認ヘッダーを含む Action.Http の例

{
  "type": "Action.Http",
  "title": "Say hello",
  "method": "POST",
  "url": "https://api.contoso.com/sayhello",
  "body": "{{nameInput.value}}",
  "headers": [
    { "name": "Authorization", "value": "" }
  ]
}

ユーザーの身元の確認

すべての要求に含まれるベアラートークンには、そのアクションを実行した Office 365 ユーザーの Azure AD ID が含まれています。システム内のユーザーの身元を表すものとして、必要に応じて、サービスに固有な自分のトークンを HTTP アクションの URL に含めることができます。 Microsoft は、制限付きアクセスのトークンの設計方法と、サービスでの使用方法を規定しません。このトークンは Microsoft に対して不透明であり、単純にサービスに返されます。

サービスに固有のトークンは、サービス URL と特定のメッセージやユーザーとの関連付けに使用できます。サービスに固有のトークンを使用する場合は、アクションのターゲット URL の一部として使用するか、サービスに戻ってくる要求の本文に使用することをお勧めします。次に例を示します。

https://contoso.com/approve?requestId=abc&serviceToken=a1b2c3d4e5...

サービスに固有のトークンは、関連付け ID として機能します (userID、requestID、salt を使ったハッシュトークンなどの場合)。これにより、サービスプロバイダーは生成するアクション URL を追跡し、送信し、受け取るアクション要求と一致させることができます。関連付けに加えて、サービスプロバイダーはサービスに固有のトークンを使って再生攻撃から自分自身を保護することもできます。たとえば、同じトークンを使って既にアクションが実行されている場合には、サービスプロバイダーは要求を拒否することを選択する場合があります。