Security from Zero、第5回：アカウント、認証、アクセス

「ログインには成功したのに、なぜファイルを開けないのか」「パスワードを変えたのに、なぜアプリはまだ要求を受け付けるのか」。別々のサポート案件のようですが、共通するのは、サインイン、操作の権限、セッションの継続は別の仕組みだという点です。

第3回ではローカルのユーザーと権限を確認しました。第4回では、ログオンの結果だけで安全・危険を決めない読み方を学びました。今回は、その考え方をWebサイト、クラウド、自動処理が使うアカウントにつなげます。

用意するもの： ブラウザー、テキストエディター、架空の教材ファイル、第5回ワークブック。中心の演習にWindowsの管理者権限、クラウドのテナント、有料のセキュリティ製品は必要ありません。目安は約4時間です。読むのに約90分、2つの演習に約1時間を使い、残りを答え合わせと説明の練習に充ててください。

8枚の図は独自に作成した教材で、製品のスクリーンショットではありません。選ぶと原寸で開けます。実際のパスワードやセッションCookieの開示、認証方法の登録、勤務先の権限変更を求める作業はありません。

1. 1回のサインインの背後にある4つの問い

問い	用語	例	まだ分からないこと
どのアカウントを名乗っているか	識別	mira-01 と入力する	そのアカウントの認証器を制御できるか。
結び付いた認証器を制御していると証明できるか	認証	パスワードとワンタイムコード、またはパスキーでの認証	操作が本人の意図したものか。何をしてよいか。
この対象に、この操作を、今行ってよいか	認可（アクセスの許可）	財務の請求書を読むが、支払承認はできない	次の要求にも同じ許可があるか。
認証済みの状態をどう継続するか	セッション管理	次の要求でアプリがセッションCookieを受け付ける	そのセッションが有効で保護され、要求の権限も満たすか。

図1. 各関門が答える問いは異なります。セッションを覚えていても、アクセスの確認は必要です。

**ID（アイデンティティ）**は、人、自動処理などの主体を表します。アカウントは特定のシステムで使う記録です。認証器はパスワードや暗号鍵など、制御していることを証明するためのものです。権限は操作を許し、ロールは権限をまとめます。グループはアカウントの集合で、ロールの割り当てに使われることがあります。セッションは後続の要求を認証済みの状態と結び付けます。

1人が日常用と特権操作用のアカウントを別々に持つことがあります。異なるディレクトリに同じ表示名がある場合も、メールアドレスが変わる場合もあります。実際の証跡には、名前だけでなく、テナントやディレクトリと、そのシステムの安定したアカウント識別子を残してください。ただし、それだけで操作した人物が決まるわけではありません。

確認： 同僚のユーザー名を入力するのは識別です。その人物の認証にも、ファイルを読む許可にもなりません。

2. どの種類のアカウントかを確かめる

種類	主な用途	有用な管理	調査時の問い
個人に割り当てた通常アカウント	メール、文書、日常業務	個別の利用者、適切なMFA、必要最小限の権限	この人の仕事で通常必要な操作か。
特権操作用アカウント	承認された管理作業	日常用との分離、期限付きの昇格、強い認証と監査	どのロール、範囲、承認で変更できたのか。
ゲスト・契約者アカウント	期間を限った共同作業	社内の責任者、有効期限、共有先の見直し	契約と作業にまだ合ったアクセスか。
ワークロード・サービスID	定期エクスポート、アプリ、連携	所有者、狭い権限、対応する場合は短期の資格情報やワークロードフェデレーション	自動処理が対話型サインインをしているのはなぜか。
緊急アクセス用アカウント	通常の経路が使えない場合の復旧	別途設計した保護、監視、検証済み手順	想定・承認された利用で、事後確認もされたか。

サービスIDは、スマートフォンで「承認」を押せる人ではありません。だからといって、自動処理用の全アカウントをあらゆる制御から除外するべきではありません。処理に適した認証方法を用い、必要な操作だけを許します。対応する環境では、マネージドIDやワークロードフェデレーションで保存する秘密情報を減らせますが、権限や所有者の管理は依然必要です。

人が共有するアカウントでは、記録に残るのは共有資格情報であって、使った人物を追いにくくなります。サービスの所有者は、目的、呼び出し元、権限、資格情報の寿命、無効化時の影響を説明できる必要があります。この教材の練習のために、本番の連携を無効化してはいけません。

3. パスワード：繰り返し使える秘密を守る

パスワードは「知っているもの」です。使い回すと、別サイトの漏えいや巧妙なフィッシングから、同じ秘密が攻撃者に渡る恐れがあります。HTTPSは通信経路を保護しますが、接続先の運営者が信頼できることまでは示しません。

個人のアカウントでは、信頼できるパスワードマネージャーで、サービスごとに長く一意なパスワードを生成・保存してください。マネージャー自体も強いマスター用の秘密と適切な追加要素で保護し、復旧方法を理解します。自分でパスフレーズを作るなら、有名な文章、個人情報、以前のパスワードの小変更ではなく、予測されにくい語の組み合わせを選びます。

管理されたアカウントでは組織の方針に従い、侵害の疑いは所定の手順で報告してください。定期変更だけでは、使い回し防止、フィッシング耐性のある認証、適切な復旧、調査の代わりにはなりません。秘密が露出すれば変更は必要ですが、後で学ぶとおり、それだけで封じ込めが終わるとは限りません。

サービスの設計を見るなら、試行回数の制限、よく使われる・漏えいしたパスワードの検査、適切な保存、リセット経路を確認します。実在する人のパスワードを推測して試してはいけません。パスワードのハッシュ化と暗号化は別であり、照合のために元の平文を復元する必要がない設計が基本です。

教材に印刷されたパスワードを、自分のパスワードにしてはいけません。 ダウンロード内の資格情報らしく見えるラベルは、アカウントやセッションの参照名で、使える秘密情報ではありません。

4. MFA：画面の数ではなく、要素を数える

**多要素認証（MFA）**は異なる種類の根拠を組み合わせます。2段階の操作が、自動的に2要素になるわけではありません。

要素	例	注意点
知っているもの	パスワード、適切な認証器を有効にするローカルPIN	パスワードと秘密の質問は、知識を2回使うだけです。
持っているもの	セキュリティキー、OTPや暗号鍵を保持する認証器	スマートフォンを持っているだけで認証が完了するわけではありません。
身体的な特徴	認証器を有効にする指紋や顔	こうした設計では認証器と組み合わせます。指紋を遠隔のパスワードとしてサイトへ送るわけではありません。

図2. 異なる要素の種類を数えます。1台の機器で多要素の認証器を実現する場合もあります。

認証アプリの**TOTP（時刻に基づくワンタイムパスワード）**は定期的に変わります。パスワード単独より有用ですが、攻撃者がフィッシングの画面に現在のコードを入力させ、有効な間に中継することは可能です。SMSには電話番号や配送経路に関するリスクもあります。プッシュ要求の連打は承認を誘うことがあり、番号の照合で文脈は改善しても、暗号的なフィッシング耐性と同じではありません。

身に覚えのない要求は拒否し、既知の連絡経路で報告してください。不審なメッセージが示す復旧リンクではなく、自分で正規のサービスを開いて活動を確認します。「IT担当」を名乗る電話の指示だけで承認してはいけません。要求の到着は調査すべき情報ですが、それだけでパスワードが受理された証拠とも限りません。認証の流れや記録は製品によって異なります。

ログの**「MFA条件を満たした」**は、今回新たに認証した場合だけでなく、既存の認証情報やポリシーが認めた条件を指すこともあります。方法の詳細、時刻、提供元の定義を確認してください。要約フィールドを「本人が内容を理解して承認した」と読み替えないことが重要です。

5. パスキー：鍵が何を証明するのか

パスキーは公開鍵による認証を使います。登録を単純化すると、認証器が鍵のペアを作り、サービスが公開鍵と資格情報の識別子をアカウントに結び付けます。秘密鍵は認証器が管理し、設計によっては端末に結び付く場合も、提供元を通じて保護・同期される場合もあります。

サインイン時、サービスは新しいチャレンジを送ります。認証器は必要なローカルの利用者確認を行い、所定の認証データに署名します。サービスは登録済み公開鍵で証明を検証し、チャレンジや利用先の文脈も確認します。ブラウザーと認証器は、該当するサイト・オリジンへの結び付きを確認します。暗号化したパスワードを送るだけの仕組みではありません。

図3. サービスが確認するのは暗号的な証明です。指紋やローカルPINを、再利用可能なログイン用の秘密として受け取るわけではありません。

このサイトへの結び付きにより、正しく実装されたWebAuthn/FIDO認証は、通常の資格情報の中継型フィッシングに耐性を持ちます。ただし、すべての操作が安全になるわけではありません。解除済み・侵害された端末、盗まれたアプリのセッション、弱い復旧経路、過大な権限は別の問題です。サービスが認めていれば、弱い方法へのフォールバックもあり得ます。

すべてのパスキーが1台の端末だけに残る、すべて同じ利用者確認設定で動く、生体認証なら常に同じ保証になる、とは考えないでください。サービスと認証器の設定を確認します。個人アカウントの設定を変える前に、独立した復旧経路を確かめ、電話、キー、同期用アカウントを失った場合を理解してください。仕事では、提供されている登録・復旧の手順を使います。

確認： パスキーがサインインを強くしても、請求書の承認権限が付くわけではない理由を説明してください。

6. セッションとSSO：毎回聞かれない理由

セッションは、完全なサインインを毎回やり直さずに、後の要求を識別する仕組みです。Cookieやトークンがよく使われます。有効期間内でほかの検査も満たせば、持っているだけで使えるBearer型の秘密として働く場合があります。トークンが必ずJWTとは限らず、読める形式をデコードすることと、正しく検証することも別です。

**シングルサインオン（SSO）**では、**IdP（IDプロバイダー）**がアプリのために利用者を認証します。アプリは利用先、またはリライングパーティーとも呼ばれます。アプリ側が所定のアサーションやプロトコルの応答を検証し、独自のセッションを作ることがあります。それでも、アプリの認可ポリシーは必要です。会社のポータル経由で入ったからといって、すべてのアプリで同じ権限があるわけではありません。

図4. 認証で状態を確立しても、アプリはその有効性とアクセス規則を継続して確認する必要があります。

行ったこと	決め付けてはいけないこと
タブを閉じた	サーバー側のセッションも終わった。
1つのアプリからサインアウトした	すべての端末、アプリ、IdPのセッションも終了した。
パスワードをリセットした	すべてのセッション、アクセストークン、連携用資格情報が直ちに無効になった。
セッション失効を要求した	すべてのアプリで既に強制された。トークンやセッションの種類で挙動は異なります。
ロールを外した・アカウントを無効にした	キャッシュされた権限や発行済みトークンも瞬時に変わった。

承認された対応では、必要な証跡を残し、提供元がサポートする封じ込めを行い、対象アプリを特定して結果を確認します。失効APIの成功は要求が受理された根拠であり、発行済みの資格情報がすべてのリソースで拒否された証明ではありません。その後のアプリの活動、ポリシーの反映、トークンの寿命、サービス固有のセッション制御を確認してください。

実際のCookie、Bearerトークン、復旧コード、認証アプリのQRコードを、チケット、公開リポジトリ、ポートフォリオに載せてはいけません。秘密の値ではなく、承認された照合用の識別子を使います。教材の s-mira-A は無害な参照名で、Cookieではありません。

7. 認可：ロール、操作、対象、時刻を合わせる

最小権限とは、必要な作業を行える範囲で、不要な能力、対象範囲、期間を与えないことです。財務担当だけが必要な請求書を、全員が読めるなら最小権限とはいえません。作業後に承認ロールを外すことも、作業前に強い認証を求めることと同じく重要です。

**RBAC（ロールベースのアクセス制御）**は、ロールを通じて権限を割り当てます。実際には、対象の所有者、端末の状態、場所、認証の保証、時刻などを評価する仕組みもあります。グループ名だけで権限は決まりません。実際の割り当てから、ロール、操作、対象範囲をたどり、直接付与や期限付きの昇格も確認します。

教材の規則は意図的に単純です。許可は加算され、明示的な拒否や入れ子のグループはなく、操作と対象範囲の一致が必要です。アカウントは有効で、許されたサインイン経路を使います。self の許可は、そのアカウントが所有するプロフィールだけに適用します。期限付きロールは開始時刻を含み、終了時刻そのものは含みません。実製品の優先順位や評価規則とは異なるため、汎用のACLアルゴリズムとして扱わないでください。

図5. 要求された操作まで許可をたどります。「admin」という名前が、すべてのデータへのアクセスを与えるわけではありません。

演習では、通常アカウント mira-01 と特権操作用の mira-admin-01 を分けています。後者は架空のディレクトリでアクセスを管理できますが、現在の付与には請求書の閲覧がありません。将来の割り当てを変更できること自体は強い権限であり、統制と監査が必要です。このモデルは管理者が自分に新たな権限を付ける操作までは再現しません。

8. 演習A：10件のアクセスを判断する

教材JSONの policy、accounts、requests を開いてください。events は別の事例なので、今は使いません。ワークブックで次の順番に確認します。

1. account_id でアカウントを探し、enabled と channel を確認する。
2. 所属グループを policy.groups でロールへ展開する。
3. 要求のUTC時刻に有効な期限付きロールを加える。
4. action と resource_scope が完全に一致する許可を探す。
5. self なら resource_owner とアカウントIDも比べる。
6. 許可・拒否と決め手を記録する。認証に成功しても、不足している権限は増えない。

答えを見る前に10件すべてを判断してください。

要求	アカウントと操作	期待される判断	このモデルでの決め手
R1	mira-01：09:05に財務の請求書を読む	許可	finance_readers が invoice_reader を与える。
R2	mira-01：09:05に財務の請求書を承認	許可	期限付きの invoice_approver が有効。
R3	mira-01：09:15に財務の請求書を承認	拒否	許可は09:15:00Zちょうどに失効する。
R4	ren-01：財務の請求書を読む	拒否	操作と対象範囲を与えるロールがない。
R5	mira-admin-01：財務の請求書を読む	拒否	ディレクトリ管理ロールは請求書の閲覧を許可しない。
R6	mira-admin-01：ディレクトリのアクセスを管理	許可	identity_admin が directory の access.manage を与える。
R7	svc-invoice-01：ワークロードとして請求書を読む	許可	経路と請求書の閲覧許可が一致する。
R8	svc-invoice-01：対話型で請求書を読む	拒否	この演習ではワークロード経路に限定されている。
R9	ren-01：Miraのプロフィールを読む	拒否	自分用の許可では別アカウントのリソースを読めない。
R10	ren-01：Renのプロフィールを読む	許可	アカウントIDと所有者が一致し、自分用の許可に合う。

答え合わせ： 許可5件、拒否5件です。R3は「だいたい近い時刻」ではなく境界の問題、R5は「admin」という単語ではなく実効権限の問題です。R9はサインインの有無ではなく、対象の所有者を確認する問題です。

実在する請求書やプロフィールのAPIに要求を送らないでください。紙の上で静的なポリシーを評価する演習であり、ペネトレーションテストではありません。

9. アカウントのライフサイクルと復旧もアクセス制御

段階	見直すこと	残す根拠
参加・入社	確認済みの依頼、所有者、基本ロール、所定の認証・復旧の登録	誰がどの範囲を承認し、いつ始まり、一時アクセスがいつ終わるか。
異動・役割変更	新しい業務だけでなく、以前の直接付与や委託先の権限の削除	前後の実効権限、承認、期限の確認。
離任・退職	アカウント、アプリのセッション、ロール・グループ、ゲスト、ワークロードの所有者	サインインの無効化に加え、サービスごとに実際に止まったことの確認。
復旧	認証器の紛失、またはアカウント侵害の疑い	承認された経路での本人確認、置き換えた方法、復旧情報とセッションの点検。

図6. 認証を強くしても、弱い復旧や古い権限の蓄積で保護が崩れることがあります。

漏えいした名前、生年月日、電話番号は、強い本人確認にはなりません。ヘルプデスクは、話のうまい電話相手や、その場で新しく指定された番号を信じるのではなく、組織の確認手順を使う必要があります。復旧コードも秘密として保護し、復旧したい唯一の端末だけに保存しないようにします。

本人のアカウントを削除しても、知っていた秘密や、許可したアプリのアクセスがすべて消えるわけではありません。必要に応じて委任アクセス、APIキー、自動処理の所有者を確認します。資格情報の変更・失効は承認された手順で依存関係と結果を確かめ、業務サービスが使う秘密を無差別に変更してはいけません。

10. 演習B：パスワード変更後も続くセッションを調べる

次に case_note と events を読みます。2026年10月27日、UTCの架空の10イベントが、単純化した3種類の出典から記録されています。フィールド名は教材用で、CrowdStrike、Windows、Entraのスキーマではありません。登場アカウントは共通ですが、演習Bは別の事例で、演習Aのポリシーを完全に再生したものではありません。

Miraが身に覚えのないMFA要求を報告しました。この報告も残して確認すべき情報ですが、すべてのイベントの結論にはなりません。次の記録を読みます。

参照	UTC	出典と記録された観測	決め付けてはいけないこと
E01	09:00:00	サインイン成功、password+totp、参照 s-mira-A	正当な利用者が意図してサインインした。
E02	09:04:00	アプリの請求書閲覧に成功	後の操作もすべて許可・想定されている。
E03	09:10:00	復旧方法の追加に成功	本人が認めた変更である。
E04	09:11:00	別のサインインを拒否、理由 mfa_denied	既存のセッションも終了した。
E05	09:12:00	s-mira-A でエクスポート開始に成功	ダウンロード完了、量、または新しいMFAが確認できた。
E06	09:14:00	パスワードのリセットが成功と記録	すべてのアプリのセッションが直ちに止まった。
E07	09:15:00	アプリが s-mira-A の閲覧を受理	リセットでこのセッションを失効できた。
E08	09:16:00	セッション失効の要求が成功と記録	すべてのリソースで強制が完了した。
E09	09:16:30	アプリで再び閲覧に成功	成功の理由が分かる。ファイルにトークンや強制処理の内部情報はない。
E10	09:20:00	アプリが閲覧を拒否、session_not_accepted	全端末・全セッション・全アプリで封じ込め済み。

図7. リセットと失効要求は対応の操作です。その効果を調べる根拠になるのは、その後のリソース上の活動です。

192.0.2.24 と 198.51.100.17 は文書用の例示アドレスです。遮断や脅威照会の対象ではありません。実際のIPの変化でも、VPN、携帯回線、プロキシが理由の場合があります。出典をまたいで同じセッション参照を使うのは教材の設定です。実製品では別の識別子による照合が必要な場合があり、IP、名前、時刻の一致だけで同じ人物やセッションと断定してはいけません。

ワークブックの答えを見る前に書いてください。

1. 認証成功を示す記録はどれで、どの方法が実際に記録されているか。
2. パスワード変更後のアプリの成功はどれか。失効要求の後でもあるのはどれか。
3. この例では、サインイン拒否で既存のセッションも終わったか。
4. export.start から、完了、データ量、出力された項目を判断できるか。
5. 復旧情報の変更とエクスポートが想定どおりかを判断するには、何が必要か。
6. 1件の要求の拒否ではなく、関係するサービス全体の封じ込めを示すには、何を確認するか。

答え合わせ： E01の方法は password+totp。E06より後の閲覧成功はE07とE09で、E09はE08より後でもあります。E04はE05を止めていません。E05は開始であり、完了や量ではありません。アプリ監査の5件は、成功4件、拒否1件です。身に覚えのない要求と復旧方法の変更は所定の手順で上位担当へ伝える理由になりますが、この資料だけでは操作した人物や侵害は確定しません。

11. サインインのトリアージメモを作る

「別の国からログイン成功」だけでは、説明できる指摘にはなりません。次の順に状況を調べます。

図8. サインインから後の活動まで、根拠をたどります。調査と、権限を持つ担当者による封じ込めは分けてください。

確認	問い	役立つ根拠
出典とID	テナント、安定したアカウントID、時刻帯、イベント種別は何か	元の記録、出典の正常性、保持期間。
認証とポリシー	今回の認証か、既存の情報か。方法と適用結果は何か	認証ステップ、方法の登録履歴、ポリシー評価。
端末とネットワーク	想定端末・接続か、単に見慣れたIPか	端末IDや状態、その時刻の承認済みVPN・資産情報。
アプリでの操作	その後、何を読んだ・変えた・付与した・出力したか	対象ID、監査、セッションの照合、出力の完了と量。
アカウント変更	復旧情報、アプリ同意、ロールは変わったか	ID監査と承認、直接・期限付きの権限。
封じ込めの効果	必要な場所でアクセスが止まったか	対応操作の記録、有効期限・失効の動作、その後のリソースのログ。

教材について説明できるメモは、例えば次のようになります。「Miraが身に覚えのないMFA要求を報告。E03は復旧方法の追加、E05は出力開始を記録。アプリはパスワード変更と失効要求の後にも、同じ参照の要求を受理した（E07、E09）。E10は後の1件の拒否を記録。操作の意図、出力完了、ほかのセッションの状態は不明」。

次の依頼も具体的にします。元のログを保全し、既知の経路で想定された活動かを確認し、認証、復旧変更、出力、端末の詳細を取得する。権限を持つ対応者に、対象のアカウント・セッション制御を実施し結果を確認してもらう。パスワードを変えただけで「安全」、出力開始だけで「データ窃取」と書いてはいけません。

12. 任意のローカル確認：現在のアカウントとクラウドのロールは別

自分のWindows PCでは、コマンドプロンプトで現在のアカウントのSIDと、現在のセキュリティトークン内のグループを確認できます。

whoami /user
whoami /groups

自分のLinuxでは、次を使えます。

id

ユーザー名と識別子を読み、別サービスのロール付与と区別してください。Windowsのトークンには拒否専用などの属性を持つグループも含まれ得るので、管理者グループの名前があるだけで、現在のプロセスの昇格を証明できません。これらのコマンドは、Microsoft 365、SaaS、クラウドの全権限を列挙するものではありません。最近の所属変更も、その仕組みで必要な更新までは既存トークンに反映されないことがあります。

実際の識別子は公開しないでください。ポートフォリオにはローカル確認を行った事実だけを記すか、教材の架空アカウントを使います。中心の演習に、グループの変更、管理者への切り替え、他人のアカウントの閲覧は必要ありません。

13. 理解を確認し、ポートフォリオに残す

問い	答えに含めたい点
パスワードと秘密の質問はMFAか	両方とも知識。画面ではなく要素の種類を数える。
ローカルPINがあれば、パスキーも単なるパスワードか	手元で暗号認証器を有効にでき、サービスが検証するのは暗号的な証明。
サインイン後にアクセス拒否されるのはなぜか	認証と認可は別。操作、対象、範囲を調べる。
「admin」がR5で拒否されるのはなぜか	このモデルの許可はディレクトリ管理で、請求書の閲覧ではない。
09:15ちょうどのR3を拒否するのはなぜか	教材の期限は終了時刻を含まない。
パスワードを変えれば封じ込めは終わるか	必ずしも終わらない。対象のセッション、資格情報、アプリを特定して結果を確認する。
MFA成功やIP変更で結論が出るか	それだけで本人の意図、後続の活動、侵害は決まらない。

完成したワークブックには、理由付きの10件の判断、参照番号付きUTC時系列、アカウントとセッションの調査メモ、短いアクセス点検表が残ります。実績の表現は「架空のロール・対象範囲のポリシーを評価し、IDとアプリの監査記録を分析し、認証・セッション・封じ込めの限界を説明した」が正確です。実テナントの管理や実侵入の調査を行ったとは書かないでください。

次はロードマップの第6回、不審メールのトリアージです。メッセージは資格情報の窃取、承認の誘導、復旧先の変更を狙うことがあります。今回の知識で、アクセスのどの部分を狙っているかを考えられます。

出典、範囲、実行について

• NIST SP 800-63B-4：認証と認証器の管理。要素、フィッシング耐性、認証器のイベント、セッション、同期可能な認証器を参照。NIST自身のリポジトリの本文を確認しました。
• NIST SP 800-63C-4：フェデレーションとアサーション。IdP、利用先、アプリのセッションの区別について、公式リポジトリの本文を参照しました。
• OWASPの認可チートシート、セッション管理チートシート、パスワード復旧チートシート。公式リポジトリのMarkdown本文で、最小権限、要求ごとの検査、セッションの無効化、復旧の扱いを確認しました。
• 任意のローカルコマンドはMicrosoftのwhoami、GNU Coreutilsのidを参照できます。本記事の作成で、学習者のWindowsやLinux上で実行したものではありません。

参考本文の確認日は2026年10月28日です。ネットワーク制限によりNISTのWebホストとCISAのページは取得できなかったため、読めていないCISA資料ではなく、取得できたNISTとOWASPの公式リポジトリ本文に基づきます。標準やチートシートは概念の説明であり、特定の勤務先の規則や、全製品の失効動作を示すものではありません。

JSON、権限の答え、イベント参照、図のラベルは公開準備環境で確認します。実際のIDテナント、サインイン、認証方法の登録、リセット、失効の操作は試していません。ワークブックは架空の情報だけを使います。検知シグネチャや本番のアクセス制御コードとして使うものではありません。

2026年10月28日： 英語・日本語で作成。ロードマップに戻る。