証拠があれば答えられる質問をする
企業認証アンケートでは、ビジネス要件を、サポートされる動作、運用責任、受け入れ証拠に結び付ける必要があります。 「はい」または「いいえ」で答える機能に関する質問の長いリストには、重要な制限が隠されている可能性があります。サプライヤーは幅広いカテゴリをサポートしている一方で、購入者が必要とする特定のテナント、ライフサイクル、または導入動作をサポートしていない可能性があります。したがって、アンケートでは、何がサポートされているか、どのような構成で、誰が操作しているか、および回答をどのように検証できるかを尋ねる必要があります。
この記事はアンケートの構造を提案するものであり、 EmailAuthリストされている機能を実装するとは述べていません。サプライヤーには連絡がなく、アンケートの回答も得られませんでした。 Microsoft の責任共有に関するガイダンス そして Azure のマルチテナント ID ガイダンス 重要な区別の公式の例を提供しますが、それらは評価対象の製品からの現在の証拠に代わることはできません。
スコープと意思決定の所有権から始める
提案された顧客集団、ドメイン、送信ワークフロー、展開オプション、必要な統合、および対象となる管理者を記録します。どの要件が必須で、どの要件が優先事項で、どの要件に資格のある法律、セキュリティ、または商業のレビュー担当者が必要かを特定します。範囲が定義されていないアンケートでは、別のエディションまたは環境に対して技術的に正しい回答が得られる可能性があります。製品バージョンを保存し、各回答とともに参照を提供します。
実装されたサポート、構成に依存するサポート、計画された作業、およびサポートされていない要件を区別するようサプライヤーに依頼してください。ロードマップの日付を現在の機能に変えないでください。応答が別のサービスに依存している場合は、その依存関係と責任者を特定します。買い手は自身の義務も文書化する必要があります。必要な顧客のDNS 、アイデンティティ、またはアクセスの決定が未定義のままでは、サプライヤーは完全なワークフローをデモンストレーションすることはできません。
アイデンティティ、役割、テナント境界をカバーする
ユーザーがどのように認証されるのか、ID がどのようにテナントにバインドされるのか、ドメイン、レポート、エクスポート、管理操作にアクセス許可がどのように割り当てられるのかを尋ねます。 Azure の ID ガイダンスでは、認証とロールベースまたはリソースベースの承認および商用資格が区別されます。これらの違いを個別の質問に反映させてください。 SSO がサポートされているという記述は、顧客の分離や既存のセッションに対する役割の削減の影響を確立するものではありません。
サービス ID、ユーザー ライフサイクル、サプライヤー サポート アクセス、監査証拠に関する質問を含めます。プロビジョニング統合がすべてのアクセス パスを処理すると仮定するのではなく、無効化と失効の動作についての最新の説明を要求します。あるテナントが別のテナントのリソースを読み取り、エクスポート、または変更できないことを証明する、承認された合成陰性テストを依頼します。製品のスクリーンショットや役割リストだけでは、その証拠は得られません。
認証観察がどのように取得されるかを尋ねる
プラットフォームが取り込むソース、そのカバレッジがどのように記述されるか、サポートされていない観測や欠落している観測がどのように表現されるかを文書化します。 RFC 9990 定義する DMARC 独自のレポート検出および配信プロセスを備えた集計レポート。プラットフォームのレポート解析機能は、すべての受信者がレポートを送信すること、またはすべての正当な送信者が期間内に存在することを保証するものではありません。
製品がどのように元のレポートの出自を保持し、重複を処理し、解釈の限界を説明するかを尋ねてください。プロバイダ配信イベントと認証レポートを組み合わせる場合は、どの識別子がリンクを許可するのか、結論がメッセージ レベルなのかストリーム レベルなのかを確認してください。認証データからのユニバーサル配信保証を要求しないでください。アンケートは、完全にカバーしているという根拠のない主張を奨励するのではなく、製品の観察境界を見えるようにする必要があります。
導入と運用の責任を明確にする
現在サポートされている導入オプションと、それぞれに何が含まれているかを確認してください。インフラストラクチャにパッチを適用し、アプリケーションを更新し、ID を管理し、取り込みを監視し、リカバリを実行し、インシデントを処理する担当者を定義します。 Microsoft の責任共有フレームワークは、義務がサービス モデルによって異なる理由を示していますが、実際のサプライヤーは独自のサポートされた割り当てを提供する必要があります。共有とマークされた応答では、単にチェックボックスを 2 者間で分割するだけでなく、ハンドオフと検証の所有者を説明する必要があります。
プライベートまたは専用のオプションについては、ネットワーク パス、データ処理、サポート アクセス、外部依存関係について個別に問い合わせてください。アーキテクチャのラベルから分離を推測しないでください。サイジングには、関連する境界と透過的なワークロードの仮定に関する証拠が必要です。アンケート自体は、展開、ファイアウォールの変更、またはデータ転送を承認するものであってはなりません。これらのアクションには、承認された個別の実装作業が必要です。
データ処理と監査の要件を含める
どのようなデータが保持されるのか、サポートされている構成ではデータがどこに配置されるのか、誰がデータにアクセスできるのか、保持、削除、エクスポートがどのように行われるのかを尋ねます。プライマリ データ、ログ、バックアップ、サポート アーティファクトを区別します。この記事は、法的遵守を判断したり、ベンダーの常駐行動を主張したりするものではありません。適切な適格所有者は、現在の証拠を使用して契約要件および規制要件を検討する必要があります。
監査可能性を確保するには、どのアクションが記録されるか、拒否された試行が含まれるかどうか、アクターとテナントのコンテキストがどのように表現されるか、誰が保存設定をエクスポートまたは変更できるかを尋ねます。 Microsoft Entra 監査ログのドキュメント これは公式のアクティビティ ログの説明の一例であり、別の製品の対象範囲を証明するものではありません。監査という言葉を完全な答えとして受け入れるのではなく、製品固有のサンプルと制限を要求します。
ワークロードと商業上の前提を透明化する
承認された組織の入力を使用して、予想されるドメイン、テナント、ユーザー、レポートの量、保持および統合の頻度を述べます。推定値と未知数を明確にマークします。月に満たない観測では、正確な年間ワークロードの予測がサポートされない可能性があります。どの変数が見積もりに影響するか、および変更がどのようにカウントされるかをサプライヤーに尋ねます。ただし、技術文書から価格やパッケージ内容を推測しないでください。
商業的な包含と技術的な受け入れを分けてください。機能はオファーに含まれている場合がありますが、それでも構成と証拠が必要です。実証された機能は、提案されたパッケージの外にある可能性があります。承認された見積が存在する場合にのみ、見積の有効性、範囲、および除外を記録します。この原稿は、価格、割引、コストモデル、または調達に関する推奨事項を作成するものではありません。
要件と証拠のワークシート
要件、ビジネス上の理由、優先順位、サポートされている構成、サプライヤーの応答、証拠ソース、レビュー担当者、受け入れテスト、制限および決定の列を作成します。入力、ソース、日付、信頼度、および間違っている場合の影響を含む仮定レジスタを追加します。各必須要件を広範なマーケティング ページではなく、具体的な証拠アイテムにリンクします。沈黙をサポートとして解釈するのではなく、答えのない質問をギャップとして保持します。
テスト可能なコントロールについては、認可された治具と期待される結果について説明します。契約上の約束については、関連する承認済みの契約を特定します。運用上の責任については、指定された所有者を特定して引き継ぎます。これらの証拠タイプは相互に補完できますが、無差別に置き換えるべきではありません。契約では、技術テストを実証することなく責任を割り当てることができます。テストが成功すると、サポート契約を結ばずに動作を確認できます。
架空の診断: 完全に見えるアンケート
架空の購入者は、SSO、エクスポート、プライベート展開、および監査ログに対して肯定的な回答を受け取ります。レビューでは、最初にアンケートが完了したことがマークされます。 2 番目のレビュー担当者は、どのエディションがこれらの機能をサポートしているか、エクスポートでテナント境界が維持されるかどうか、無効化後にアクティブなセッションはどうなるのかを尋ねます。元の回答では、結果ではなくカテゴリについて説明しているため、これらの質問は解決されません。
提案されている対応策は、範囲を絞った証拠を要求し、影響を受ける要件をレビューされるまで未公開のままにすることです。買い手は供給者を虚偽表示で非難する必要はありません。単に質問内容が曖昧すぎたのかもしれません。このシナリオは架空のものであり、実際のサプライヤーの反応や製品のギャップについては説明されていません。外部との通信やテストは行われませんでした。
推奨事項とのギャップを公開する
有用な評価では、サポートされている要件、受け入れられている制限、未解決の証拠、決定を変える可能性のあるワークロードの仮定を特定します。この文書は、技術所有者とビジネス所有者の両方が、それぞれの異なる責任を分散することなく読みやすいものである必要があります。その方法と制限が明示的に承認されていない限り、証拠を超える精度を暗示する数値スコアは避けてください。
カタログには、要件と証拠のマトリックス、および透過的なワークロードまたはコストの仮定が必要です。これらのオリジナルのアーティファクトはオープンなままです。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。このドラフトはフレームワークと架空の演習を提供するものであり、ベンダーのデューデリジェンスやEmailAuth機能の主張を完了したものではありません。