認証プロダクト仕様書デザイン

Northwind 2FAブリーフ

このOpenDesign公式サンプルは、Northwindアプリの二要素認証に関する説明用のプロダクト仕様書です。冒頭で文書をDraft v0.4と位置付け、担当者、更新日、4人のレビュアーを示したうえで、TOTPとセキュリティキーの要素をログインフローに追加するという提案を記載しています。

ビジュアル構成では、この依頼内容を計画の詳細より先に配置しています。メタデータの行には、チームとしてIdentity Platform、エンジニアリングリードとしてPriya Banerjee、デザインリードとしてSasha Lin、目標ローンチとしてEnd Q4 (Dec 18)、工数見積もりとして~6 eng-weeks（エンジニアリングの作業量）が示されています。この順序により、読者は課題を読む前に担当と提供上のプレッシャーを理解できます。

続くProblemセクションでは、この提案が必要な理由を示します。直近6件のエンタープライズセキュリティ審査のうち3件で、2つ目の要素がないことを指摘されたと説明し、その後にPioneer RoboticsのMaya Reddyによる別枠の引用を置いています。この引用により、より広いセキュリティ上の主張を置き換えることなく、商業上のプレッシャーを明確に伝えています。

3つの認証の動き

サンプルのUser Storiesセクションでは、3つの業務を示しています。ワークスペース管理者は、明記された統制レビューの目的のために2FAを必須にしたいと考えています。日常的なメンバーは、2分未満でTOTP登録を完了したいと考えています。サポートエンジニアは、2つ目の要素を回避しないリカバリーパスを必要としています。これらは文書内の計画要件であり、認証が機能することやコンプライアンスが達成されたことの証拠ではありません。

これらのストーリーは3つの番号付きの横長の行として示され、各文の中でペルソナを表すフレーズを強調しています。この繰り返し構造により、責任の違いを比較しやすくなっています。また、「so that」節によって、それぞれの依頼の背後にある業務上の理由も保たれています。

この順序からは、デザイン上のトレードオフも見えてきます。ワークスペースでの強制適用がポリシーの範囲を定めるため、管理が最初に置かれています。登録はメンバーが直ちに行う操作であるため次に続きます。リカバリーサポートは例外時の経路を記述するため最後に置かれています。したがって、この文書はセキュリティをログイン画面だけでなく、共有されるシステムとして扱っています。

01

ワークスペース管理者

統制レビューを支援するため、すべてのメンバーに2FAを必須にします。

02

日常的なメンバー

通常の業務を離れることなく、TOTPアプリをすばやく登録します。

03

サポートエンジニア

追加されたセキュリティ制御を弱めることなく、リカバリーを支援します。

目標、測定方法、フェーズ

この文書の中盤では、スコープから評価、提供へと進みます。「Goals & non-goals」では、チェック記号と乗算記号を使い、TOTP、WebAuthn、ワークスペースでの強制適用、リカバリーコード、監査ログエントリーを、SMS、SSOの置き換え、アクションごとのステップアップ認証、ホワイトラベル向けのブランド文言・トーンのカスタマイズなどの対象外の作業と区別しています。

この分離は、あらゆる認証の依頼を今回のローンチに含めてしまうことを防ぐために有効です。Authy、1Password、Google Authenticatorへの対応を明記することでTOTPの目標に具体的な境界を設ける一方、WebAuthnはEnterpriseプランに限定しています。このトレードオフは、意図的な対象範囲を示すものです。仕様書は最初のリリースを明確にする一方で、隣接するID関連の作業は分離したままにしています。

Success Metricsテーブルには、サンプルの計画行が4つあります。阻害要因が解消された案件（3件中3件）、有料ワークスペースでの導入率（少なくとも60%）、直近30日間のアカウント乗っ取りインシデント（最大1件）、リカバリーサポート負荷（チケットの1.5%未満）です。これらは目標値であり、測定済みの成果ではありません。導入率の計算式は、DAUに対する登録イベントを数えていますが、ユニークメンバーの重複排除を定義していません。また、インシデントのベースラインは「前四半期に4件」としています。このテーブルで実際のローンチを測定するには、期間とカウント規則の調整が必要です。

Rollout Milestonesでは、これらの指標を4つのフラグ付きフェーズに変換しています。TOTP登録、ログインフロー、管理者によるWebAuthnと強制適用、GAとコミュニケーションです。各フェーズには工数見積もりと具体的な内容が記載されているため、設定、ログイン、ポリシー、サポート資料にどの決定事項が影響するかを確認できます。

未解決の決定事項

最後のセクションでは、仕様書を完成した実装として提示せず、不確実性を可視化したままにしています。3つの質問が、十月28日、29日、30日の日付で、それぞれDevon Park、Priya Banerjee、Sasha Linに割り当てられています。メンバーがTOTPとセキュリティキーのどちらを選ぶのか、信頼済みデバイスのCookieをどのくらいの期間有効にするのか、管理者がメンバーの2FAステータスをどこで確認できるのか、という質問です。

これはマイルストーンの流れを補完する重要な要素です。展開計画では信頼済みデバイスのCookieと管理者による強制適用が示されていますが、未解決の質問からは、それらのポリシー上の詳細が文書内で確定していないことが分かります。これらの質問を担当者と日付のそばに置くことで、明記された十月31日の期限につながる意思決定キューをチームに提供しています。

01

要素の選択

メンバーが要素を選択するのか、利用可能な中で最も強い要素を受け取るのかを決定します。

02

信頼済みデバイス

信頼済みデバイスのCookieの有効期間に関するポリシーを決定します。

03

管理者の可視性

ユーザーリストでのステータス表示と監査ログでの可視性のどちらを採用するかを選択します。