[ ビジネス価値 ]

購入前にアクセス制御、監査ログ、テナント分離を評価する

購入者が定義したマトリックスと承認されたネガティブフィクスチャテストを通じて、アクセス制御、監査証拠、顧客の隔離を評価します。

EmailAuth研究チームによる · 8 分で読めます

【ポイント】

  • 役割の名前とデモンストレーションは、完全な制御の証拠ではありません。
  • 合成テナント全体で読み取り、エクスポート、書き込み、ライフサイクル境界をテストします。
  • 監査の対象範囲、アクセス、保持を承認動作とは別に検討します。
このページでは

証拠のある管理境界を購入する

認証プラットフォームは、役割、監査ログ、テナント分離をアドバタイズする場合がありますが、これらのラベルは、購入者の意図したワークフローでコントロールがどのように動作するかを確立するものではありません。調達評価では、誰がどの顧客のデータを読み取り、エクスポート、変更、管理できるのか、ライフサイクルの変更がアクセスにどのような影響を与えるのか、それらのアクションを記録する証拠は何かを尋ねる必要があります。管理者によるデモンストレーションが成功しても、不正アクセスの否定的なテストにはなりません。

Azure のマルチテナント ID ガイダンス 認証、認可、および商業的権利を区別します。ログイン ロールがすべてのリソースとアクションをカバーすると仮定するのではなく、これらの区別を使用して購入者の質問を構成します。この記事は要件フレームワークであり、 EmailAuthまたは別の名前付きプラットフォームが提案されたコントロールを実装すると主張するものではありません。テナントへのアクセス、権限の変更、製品の購入は行われませんでした。

最初に購入者のアクセス マトリックスを定義します

サプライヤーのロール名を確認する前に、予想されるユーザーとサービスのロール、テナントの関係、およびリソースをリストします。関連する場合、ドメイン構成、認証レポート、生データ、エクスポート、統合、ユーザー管理、商用設定が含まれます。組み合わせごとに、読み取り、作成、変更、削除、エクスポートを許可するかどうかを指定します。購入者の意図する境界は、製品の動作を評価するための基準となります。

証拠なしに、「読み取り専用」でエクスポートが除外されたり、「テナント管理者」が 1 つのテナントに限定されたりすると想定しないでください。共有サービス チームには正当に複数の顧客が必要な場合がありますが、個々の顧客ユーザーには承認されたスコープのみが表示される必要があります。それらの例外を明示的に記録します。トライアルで受け入れられた広範な役割が、黙って運用アクセス設計になるべきではありません。サプライヤーに実際の役割をバイヤーのマトリックスにマッピングし、サポートされていない区別を特定するよう要求します。

インターフェイスを超えたテナントのバインディングを検証する

テナント セレクタ または、非表示のナビゲーション項目は分離の十分な証拠ではありません。認証された ID は、サーバー側境界で要求されたリソースに対して承認される必要があります。要件には、別のテナントが所有するリソースへの参照を含む、直接読み取り、検索、エクスポート、書き込み、およびバックグラウンド ジョブが含まれる必要があります。明らかに異なるデータを持つ合成フィクスチャを使用して、偶発的なクロステナント結果を検出できるようにします。

Azure のガイダンスでは、フェデレーションの構成ミスにより、意図しないテナントにアクセスが許可される可能性があると警告しています。したがって、レビューには、ID がテナントにどのように関連付けられるか、その関連付けを誰が変更できるか、および複数のテナントに属するユーザーがスコープを選択する方法を含める必要があります。電子メールのサフィックスだけから所有権を推測したり、顧客が提供したテナント ID によってその使用が許可されていると想定したりしないでください。実際のサプライヤーは、サポートされているモデルを説明し、実演する必要があります。

監査ログに実際に何が記録されているかを尋ねる

Microsoft Entra の監査ログのドキュメント そのアイデンティティ環境の変化に関するアクティビティ記録を説明します。これは公式の監査ログ モデルの有用な例であり、別のプラットフォームが同じイベントを記録するという証拠ではありません。購入者は、自身の要件に関連する正確な製品イベント カタログ、フィールド定義、アクセス制御、保持動作、およびエクスポート オプションをリクエストする必要があります。

記録が変更を調査するのに十分なアクター、ターゲット、アクション、時間、結果、およびテナントのコンテキストを特定しているかどうかを尋ねます。ユーザー アクティビティとサービス ID アクティビティを区別し、成功したアクションと拒否された試行を区別します。単に管理上の変更があったという理由だけで、失敗した認証試行がすべてログに記録されると想定しないでください。同様に、リクエストが送信されたことを示すログには、結果として生じた変更が完了したかどうかが示されない場合があります。機密データを編集し、制限を明記した実際の例を要求します。

コントロールとしてログのアクセスと整合性を確認する

監査ログ自体に、機密の顧客情報や ID 情報が含まれる場合があります。閲覧できるユーザーを定義し、テナント全体を検索し、エクスポートし、保持を構成します。設定を変更して唯一の証拠を消去できる管理者は、個別に記録を保持する管理者とは異なる責任モデルを示します。これらのコントロールがどのように機能するかをサプライヤーに尋ねますが、現在の証拠がない限り、不変性や耐改ざん性を主張しないでください。

保持期間は、考え出された普遍的な期間ではなく、製品の実際のサポート条件と購入者の義務によって指定される必要があります。インターフェース、API、およびエクスポートされたアーカイブでどのイベントが利用可能であるか、またそれらのビューが同じ範囲をカバーしているかどうかを明確にします。タイムゾーンの処理と識別子を確認して、変更される可能性のある名前に依存せずにレコードを関連付けられるようにします。この原稿の監査記録は取得されませんでした。

テストのライフサイクルの変更とサービスへのアクセス

ロールの削減、ユーザーの無効化、資格情報の取り消しは別のイベントです。 RFC 7643 SCIM アクティブ属性について説明しますが、その最終的な意味はサービス プロバイダーに委ねられます。これは、購入者がプロビジョニングの更新によってすべての既存のセッションまたは統合資格情報が取り消されると想定できない理由を示しています。製品のセッションと非対話型アクセスの動作についての現在の説明が必要です。

受け入れ計画には、セッションが存在する間にロールが削減されるユーザー、無効化された ID、限定された範囲での統合、および承認された管理者が含まれている必要があります。エクスポートやリソースの直接操作など、それぞれのケースで意図したアクセス結果を確認します。これらは、認可された隔離環境に対する提案されたチェックであり、サプライヤーの実稼働サービスや別の顧客のテナントをテストする許可ではありません。ここではそのようなアクションは実行されませんでした。

購入者の承認ワークシート

要件、ビジネス上の理由、サプライヤーの主張、サポートされている構成、フィクスチャ ID、テナント、アクション、期待される結果、実際の証拠、未解決の制限を記載したワークシートを作成します。許可されたアクションの証拠を、拒否されたアクションの証拠とは別に保管してください。リリース後も結果を解釈できるように、製品バージョン、テスト日、環境を含めます。機能が実装されるのではなく計画されている場合は、現在の対象範囲として扱わずにそのステータスを記録します。

監査ログの場合、ログが必要なアクションごとに、予想されるイベントと観察されたレコード参照を追加します。アクセスを正しく拒否しても、期待される監査証拠が生成されないテストは、両方の基準を満たすテストとは異なる結果になります。誰が制限を受け入れるか、および補償コントロールが承認されるかどうかを記録します。調達チェックリストのスコアを将来のセキュリティの保証に変えないでください。

架空診断:エクスポートできるビューア

架空の購入者は、視聴者がドメイン設定を編集できないベンダーのデモンストレーションを見ます。購入者は最初、読み取り専用の役割を満足できるものとしてマークします。ただし、意図されたマトリックスでは、生の顧客データの一括エクスポートも禁止されています。このデモでは、エクスポート、直接のリソース要求、または別のテナントのレポートへのアクセスはテストされませんでした。観察された制限は 1 つのアクションのみを対象としています。

提案されている対応策は、欠落しているオペレーション全体にわたって認可された設備ベースの証拠を求め、その結果得られた監査記録をレビューすることです。製品が表示とエクスポートを分離できない場合、購入者は役割の名前を変更してリスクがなくなったと仮定するのではなく、その制限が許容されるかどうかを判断する必要があります。これは架空の調達活動であり、 EmailAuthや特定のベンダーに関する調査結果ではありません。

購入の結論に限界を持たせる

有用な結論は、証拠によって満たされた要件、満たされていない要件、所有者によって受け入れられた制限、およびまだ未解決のテストを特定します。これは、構成の選択を製品固有の動作から区別し、有限のテスト セットから完全に分離することを保証するものではありません。この決定は、将来のすべてのバージョンまたは構成がカバーされると主張することなく通知できます。

カタログには、アクセス マトリックスと、テナント間の読み取り、エクスポート、書き込み、ライフサイクル変更に対するネガティブ テストが必要です。これらの元のテストは未解決のままです。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。この草案は評価方法を提供するものであり、実行された証拠に基づく購入推奨ではなく、商業的な約束やアクセス許可は行われていません。

[ 取り除く ]

セキュリティ機能のラベルだけではなく、証拠のある要件と明示的な制限に基づいて購入します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

バイヤーセキュリティリード

マトリックスを定義する

必要な境界はサプライヤーのデモンストレーションの前に設定する必要があります。

次のステップ

  1. リソースとオペレーションをリストします。
  2. テナント間の否定的な証拠が必要です。

アイデンティティ管理者

ライフサイクル効果を検証する

ロールの削除と無効化は、セッションに異なる影響を与える可能性があります。

次のステップ

  1. 実際にサポートされている動作を文書化します。
  2. サービス ID とエクスポートを含めます。

調達所有者

受け入れられた制限を記録する

計画されている機能は現在実装されていません。

次のステップ

  1. 証拠のバージョンと日付を保管します。
  2. 技術的な受け入れを商業的なコミットメントから分離します。

[ よくある質問 ]

よくある質問

読み取り専用の役割は必ずエクスポートを禁止しますか?

いいえ。実際の製品マッピングを要求し、購入者の意図した区別をテストします。

非表示の UI コントロールは承認の証拠ですか?

いいえ。受け入れ計画では、承認されたフィクスチャとのサーバー側のリソース境界を検証する必要があります。

Microsoft Azure: マルチテナント ソリューションの ID に関する考慮事項

すべての監査ログには拒否されたリクエストが記録されますか?

普遍的な主張は行われません。製品の正確なイベント カタログと実際の証拠を求めてください。

Microsoft Entra: 監査ログ

Entra のドキュメントは別の製品のログを証明しますか?

いいえ。これは監査モデルの公式の例であり、 EmailAuth実装の証拠ではありません。

Microsoft Entra: 監査ログ

SCIM の無効化はセッションの取り消しを保証しますか?

スキーマだけからではありません。 active 属性の最終的な意味はサービスプロバイダー固有であるため、実際のセッションの動作を確認する必要があります。

RFC 7643 : SCIM コア スキーマ

監査レビューには何を含めるべきですか?

アクター、ターゲット、アクション、時間、結果、テナント コンテキスト、アクセス制御、カバレッジと保持 (実際の製品で必要かつサポートされている)。

サプライヤーのテナントは検査を受けましたか?

いいえ。この記事は認可された合成治具のテストを提案しており、実行された製品の結果は報告していません。

どのような証拠の扉が開いたままになっていますか?

クロステナント読み取り、エクスポート、書き込み、ライフサイクル変更に必要なアクセス マトリックスとネガティブ テストは未解決のままです。

[ 情報源 ]

情報源

  1. RFC 7643 : SCIM コア スキーマ

    セクション §3.1 共通属性 · §4.1.1 特異属性 · §4.2 グループ リソース スキーマ

  2. Microsoft Azure: マルチテナント ソリューションの ID に関する考慮事項

    セクション ユーザーにテナント データへのアクセスを許可する · ワークロード ID · SSO 用の IdP とのフェデレーション · 認可モデル · 資格とライセンス

  3. Microsoft Entra: 監査ログ

    セクション 監査ログを使用して何ができるでしょうか? · ログには何が表示されますか?

[ 用語集 ]

用語集

アクセスマトリックス
ID、テナント、リソース、および許可または拒否された操作の購入者の明示的なマッピング。
テナントの分離
強制された境界により、ID が承認されたテナント スコープ外のリソースにアクセスすることが防止されます。

Microsoft Azure: マルチテナント ソリューションの ID に関する考慮事項

監査活動記録
プロバイダーが定義したアクティビティのレコード。その範囲とフィールドは実際の製品に対して検証される必要があります。

Microsoft Entra: 監査ログ

受け入れられた制限
暗黙の保証ではなく、責任ある意思決定者によって明示的にレビューされた文書化されたギャップ。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース