会社のクラウドに、パスワードさえ分かれば入れる状態が残っていませんか。認証は、アクセスしてきた人が本人かを確かめる仕組みです。多要素認証は、異なる種類の情報を組み合わせて本人を確認します。MFAという略称も使われます。
今回の中心は、重要な機密情報を扱うクラウドで、一般の利用者と管理者の両方を多要素認証で保護することです。対象サービス、認証要素の組合せ、実際の設定を、四つの基準に沿って整理します。
図1 今回扱う全4基準 認証の対象と方法を順に確認する
多要素認証の機能があることと、自社の対象者全員に適用されていることは、別に確認します。利用者が任意で設定するだけでは、設定していない人が残る場合があります。自社が扱う情報に合わせて、適用対象を決めることから始めましょう。
業務用アカウントへの不正アクセスで情報が流出した事例
Gunosyは2026年10月26日、社内業務用アカウントのID・パスワードを第三者に不正利用され、クラウド環境や業務ツール等へアクセスされたと公表しました。検知は10月21日午後で、同日中に対象アカウントを停止しています。
メールの一部閲覧と業務ツールの利用者情報の取得が確認され、取引先担当者25名、役職員等107名の氏名・メールアドレス等が流出しました。一方、認証情報の入手経路は調査中です。同社は再発防止策として、共有アカウントの廃止、多要素認証の徹底、権限の見直し等を挙げています。
| 区別して読む点 | 公表資料の内容 |
| 確認済み | 業務用アカウントへの不正アクセスと、取引先担当者・役職員等の情報流出 |
| 調査中 | 第三者が認証情報を入手した経路 |
| 発表時点で未確認 | 同社サービスの利用者情報の流出、流出情報の悪用やインターネット上での公開 |
公表された対策から、当該アカウントで多要素認証が未設定だった、多要素認証が突破された、と断定することはできません。また、導入していれば必ず防げたという結論も、この発表からは導けません。
メールや業務ツールにも守るべき情報が入っている
この事例を自社の業務に引き付けると、顧客管理システムだけでなく、メールや普段使う業務ツールも確認対象になります。メールの本文や署名、社内の利用者一覧にも、関係者の情報が含まれるためです。これは自社の確認範囲を考えるための実務上の考察です。
多要素認証は、パスワード以外の要素も本人確認に使う仕組みです。例えば、パスワードに加えて本人が持つ機器等を確認する方式なら、パスワードを知っているという条件だけで認証を完了させない構成にできます。どの要素を使うかは、後述する4-1-3-3に沿って確認します。
情報の棚卸しとログインの設定をつなぐ
第12回で整理した重要な機密情報を、どのクラウドで取り扱うかまでたどります。ファイルの保管先だけでなく、連絡に使うメール、情報を転記する業務ツール等も、実際の使い方に沿って確認します。重要な機密情報の扱いが分かると、多要素認証を必要とするサービスを具体化できます。
4-1-3-1 すべてのIDでアクセス前に本人を確認する
一つ目の基準は、すべてのユーザIDと管理者IDについて、システムや情報機器へのアクセスを許可する前に、IDごとに設定した認証情報で本人を確認することです。パスワードはその一例で、認証の方法をパスワードだけに限定した基準ではありません。
IDの名前と認証情報の役割を分ける
IDは、誰として利用するかを識別するための情報です。認証情報は、そのIDを利用する本人であることを確かめるために使います。画面で名前を選べることだけでは、その人本人だと確認したことにはなりません。
| 確認すること | 具体的に見る内容の例 |
| 対象となるID | 通常の利用者用IDだけでなく、管理者IDも含める |
| 本人確認の方法 | IDごとに設定されたパスワード、証明書、生体情報等を使う仕組みか |
| 確認する時点 | 業務データの閲覧や管理操作等へのアクセスを許可する前か |
| 確認資料 | システム仕様、認証システムの設定や説明、実際のログイン方法 |
自己評価でも、システム仕様や認証システム等を確認します。ID一覧に名前があることだけでなく、そのIDでどのように認証するかを説明できる状態にします。この基準の対象外条件は「該当なし」です。
普段と違う入口も把握する
実務では、ブラウザーからのログインに加え、スマートフォンのアプリ、管理者用の画面等も確認します。同じサービスでもログイン方法が複数ある場合、普段使っている画面だけを見て判断すると、一部の経路を見落とすことがあります。
複数のサービスを一度の認証で利用するシングルサインオンを使う場合は、認証を担当する仕組みと各サービスの関係を整理します。これは確認のための実務例です。認証をまとめたことだけで、必要な多要素認証の設定まで済んだとは限りません。
認証と権限の管理は組み合わせて使う
本人だと確認した後でも、その人が何を閲覧・変更できるかは別の設定です。前回までのID管理と管理者権限の限定に、今回の認証を組み合わせます。退職した人のIDを止めること、不要な権限を外すことも、引き続き必要です。
4-1-3-2 重要な機密情報を扱うクラウドに常に多要素認証
二つ目の基準は、重要な機密情報を取り扱うクラウドサービスへ利用者や管理者がアクセスする場合に、常に4-1-3-3の異なる2種類以上の認証要素を使うことです。管理者だけに設定すればよいという基準ではありません。
図2 対象となるクラウドでは一般の利用者と管理者の両方を確認する
公式解説書は、3-1-4-3で把握する重要な機密情報を扱うクラウドサービスを、すべて対象としています。サービスごとに情報の取扱いと多要素認証の要否を管理し、導入前にも機能の有無を確認することを望ましい方法として示しています。
| 使い方の架空例 | この基準での確認 |
| 顧客情報を保管する | 自社で重要な機密情報とした顧客情報を扱うなら対象 |
| 社内資料を共有する | 資料の内容と機密区分を確認し、重要な機密情報の取扱い有無を判断 |
| 公開情報のみ扱う | 実際に重要な機密情報を扱っていないか、管理画面等も含めて確認 |
対象外となる条件は、重要な機密情報をクラウドサービス上で取り扱っていない場合です。機能がない、無料プランで使えない、管理者が少ないといった理由は、この対象外条件には挙げられていません。
「常に」について、画面を開くたびにコードを再入力するという回数や、認証を何日間保持できるという一律の数値は、この資料では定められていません。認証状態の保持も含め、対象のアクセスがどの要素で保護されるかを仕様と設定で確認します。
4-1-3-3 SCSでは四つの分類から異なる要素を選ぶ
三つ目の基準は、多要素認証に使う要素を、知識情報、所有情報、生体情報、その他の情報の四つの分類から、異なる2種類以上選ぶことです。一般的な三分類の説明に加え、SCSには条件付きの「その他の情報」がある点も押さえます。
図3 SCSの認証要素の分類 その他の情報には利用条件がある
数字を入力する方式でも所有情報になることがある
ワンタイムパスワードは、一定の条件で一度だけ使う認証コード等を指し、ここでは所有情報の例です。公式基準には、利用者のメールアドレスや電話番号等へ送って入力させる方式と、スマートフォンへの認証要求を使う方式も含まれます。数字を入力するという見た目だけで、知識情報に分類しないようにします。
証明書を使う場合は利用者ごとの発行を確認する
証明書には、ICカード等に格納したものと、端末にインストールしたクライアント証明書が含まれます。公式解説書では、いずれも利用者ごとに異なる証明書が必要とされています。秘密鍵を他の人が複製・持ち出しできないように保護することは、望ましい管理です。
サービスの説明に「証明書を使用」とあるだけで判断せず、誰の証明書で本人を確認するかを確かめます。全員で同じ証明書を配ればよい、という読み方はできません。
入力する回数と認証要素の種類を混同しない
パスワードを入力した後に、別の暗証番号であるPINを入力しても、両方が知識情報なら、異なる2種類にはなりません。IDとパスワードという二つの欄があることも、それだけで二要素認証を意味しません。
図4 二回入力することと異なる要素を組み合わせることの違い
パスキーは実装の内容を確認する
パスキーは、本人が持つ端末等の認証用情報を利用する方式です。公式解説書は、所持する端末内の資格情報に加え、生体認証又は端末のロック解除用パスワード等で本人を確認する構成なら、所有情報と、生体情報又は知識情報の組合せとして扱うことが考えられるとしています。
「パスキー対応」という名称だけで、すべての方式が同じ構成だとは判断できません。利用者本人を何で確認するかをサービスの仕様で確認します。端末のローカルPINと、多要素認証の知識情報として用いるパスワードも、名称や数字の桁数だけで一括りにしないようにします。
IPアドレスを使う場合には条件がある
IPアドレス等の「その他の情報」は、信頼できるネットワークからのアクセスの補助手段に限られます。公式解説書には、固定IPの制限とID・パスワードを組み合わせる例や、普段と異なるIPや国からのアクセス時に追加認証を求める例があります。
したがって、会社からの接続なら無条件で認証を省略できる、と一般化することはできません。解説書は、利用者・端末との結び付き、偽装や共有のしにくさ、認証サーバーでの検証、知識情報からの独立性を満たすことを望ましい条件として挙げています。
4-1-3-4 知識情報のパスワードは8文字以上にする
四つ目の基準は、多要素認証の知識情報として使うパスワードを、8文字以上にすることです。ここで対象となるのは、多要素認証を構成するパスワードです。ワンタイムコードの桁数に、この8文字の条件を当てはめるものではありません。
図5 8文字の条件が適用される対象を区別する
長さの設定と実際の適用を確かめる
自己評価では、認証システム等で8文字以上としていることを確認します。実務では、最低文字数の設定に加え、その設定が対象の利用者や管理者に適用されるかを見ます。設定変更前からあるIDの扱い等は、サービスの仕様に従って確認します。
パスワードそのものを提出させたり、確認資料へ書き込んだりする必要はありません。文字数のポリシーや適用範囲など、秘密を集めずに説明できる資料を使うことが、運用上の方法になります。
8文字を満たすことと推測されにくいことは別に考える
公式解説書は、さらに長くすることに加え、単純な数値列や辞書にある英単語等をパスワードにさせないことを望ましい管理として示しています。なお、推測されやすい単語を禁止する社内ルール等は、別項目の4-1-5でも扱います。今回は4-1-3-4の適用範囲を整理しています。
対象外条件は、多要素認証でパスワードを利用していない場合です。パスワードを使わなくても、4-1-3-3に沿って異なる2種類以上の要素を使うことを確認します。
機能の有無から対象者への適用まで確認する
多要素認証を使える製品でも、実際には一部の人だけが登録している、管理者だけが必須になっている、といった状態があり得ます。サービス単位で、扱う情報、対象者、ログイン方法、認証の組合せを対応させて確認します。次は実務上の整理例です。
図6 情報の管理と認証設定をつなぐ確認手順の例
| 確認記録の項目 | 架空の記入例 |
| 情報とサービス | 重要な機密情報に分類した顧客情報／顧客管理クラウドA |
| 対象者 | 一般利用者12名と管理者2名。全対象IDを一覧と照合 |
| 要素の組合せ | パスワードによる知識情報と、本人の認証アプリによる所有情報 |
| 実際の適用 | 対象グループへ必須設定。ブラウザーと管理画面等の入口を確認 |
| 残す記録 | 仕様の確認先、設定画面、適用対象、確認日と担当、未対応事項 |
一部のテストIDでログインできたことだけで、全対象者に適用されているとは判断できません。対象者一覧と適用設定を照合し、利用者・管理者の各区分やログイン経路で動作を確かめると、設定漏れを見つけやすくなります。
本人確認をまとめる認証サービスと連携している場合も、別の入口から認証を省略できないか、仕様と設定を確認します。機能や契約プランの制約がある場合は、提供者に対応方法を確認し、重要な機密情報をどこで扱うかと併せて見直します。
全4基準と自己評価の確認資料
基準への対応を説明するときは、機能名だけでなく、対象、要素の組合せ、設定の適用が分かる資料を用意します。文書や記録には、システム上の設定、管理ツール、画面表示や出力等も含まれます。
| 評価基準番号 | 確認する内容と資料の例 |
| 4-1-3-1 | 全ユーザID・管理者IDのID別認証。システム仕様、認証システム、アクセス前の認証方法 |
| 4-1-3-2 | 重要な機密情報を扱うクラウドの把握と、利用者・管理者への常時多要素認証。情報台帳、サービス仕様、適用設定 |
| 4-1-3-3 | 知識・所有・生体・その他から異なる2種類以上。認証システムと要素の組合せ、その他の情報を使う場合の条件 |
| 4-1-3-4 | 多要素認証の知識情報として使うパスワードが8文字以上。認証ポリシーと適用範囲 |
この表は確認資料の整理例で、公式の指定様式ではありません。対象外条件は、4-1-3-2では重要な機密情報をクラウド上で扱っていない場合、4-1-3-4では多要素認証にパスワードを使っていない場合です。4-1-3-1と4-1-3-3の対象外条件は「該当なし」です。
今日確認するなら重要な情報を扱うクラウドから
まず、重要な機密情報を扱うクラウドを一つ選び、一般利用者と管理者の両方に必要な認証が適用されているかを確認します。管理者画面で機能が有効という表示だけでなく、対象IDに適用する設定まで確認してください。
次に、その認証がどの分類の要素を組み合わせたものかを、図3と対応させます。二回入力するという説明だけで済ませず、本人の知識、所有物、生体等の何を確かめるかを言葉にします。
最後に、パスワードを知識情報として使う場合は長さの条件を確かめ、仕様や設定の確認結果を記録します。一つのサービスで整理した方法を、重要な機密情報を扱う他のクラウドへ広げていきます。
次回はパソコンとスマートフォンの認証試行への備え
11月16日は、4-1-4「アカウントロック制御」です。端末のログオンやロック解除を繰り返し試される場合に備え、試行間隔、失敗時のロック、設定できない場合の対応を全2基準で説明します。
連載の関連項目とご相談
第1回は連載目次、第12回は重要な機密情報の管理、第13回はユーザID、第14回は管理者IDです。認証の対象となる情報と人を、これらの回と対応させて整理できます。パスワードに関する社内ルールは第17回、パスワードの管理は第18回でも扱います。
ライトハウスコンサルタントでは、★3を見据えた現状確認や、規程・台帳・記録の準備を支援しています。クラウドで扱う情報と認証の設定を照らし合わせ、対象者や設定漏れを確認するための資料を整理するお手伝いをしています。
