認証とは？【初心者向け】

シングルサインオンのプロトコルとして SAML や OpenID Connect が一般的になりました。多要素認証した従業員に発行される許可証（SAML アサーションや ID トークン）を使って複数の業務システムを利用できますので、後述 するようなサイバー攻撃によって多要素認証を突破されてしまったら一大事です。

多要素認証

以下のような操作を 2 つ以上実行しなければログインできない仕組みです。

• パスワードを入力する
• 届いたメールや SMS に書かれたワンタイムパスワードを入力する
• ハードウェアトークンに表示されたワンタイムパスワードを入力する
• スマートフォンの認証アプリに表示されたワンタイムパスワードを入力する
• スマートフォンの認証アプリに届いたプッシュ通知をタップする
• セキュリティキーを USB ポートに挿入し、暗証番号（PIN）を入力してタッチする
• 指紋や顔などで生体認証する
• 認証用の証明書を選択する
• 社員証をカードリーダーで読み取り、暗証番号（PIN）を入力する

認証を狙うサイバー攻撃とは？

パスワードなどの認証情報を盗むことを目的としたフィッシング攻撃やマルウェアについて紹介します。仮に VPN の脆弱性対策が完璧だったとしても、認証情報が盗まれれば VPN 経由で侵入できてしまうので注意が必要です。

多要素認証疲労攻撃

「プロンプト爆撃」「MFA Bombing」とも呼ばれる多要素認証を突破する攻撃です。攻撃者が盗んだパスワードでログインを試みますと従業員のスマートフォンにプッシュ通知が届きます。このとき怪しいと判断して「いいえ」を選び、すぐにパスワードを変更すれば良いのですが、例えば深夜に何度もプッシュ通知が届いたら誤って「はい」を選んでしまう恐れがあります。

認証システムにログインできれば、その従業員に許可されたアプリにもログイン（シングルサインオン）できてしまうので一大事です。

多要素認証を回避する攻撃

ダークウェブで入手した AitM（Adversary-in-the-Middle：真ん中にいる敵）攻撃キットで偽サイトを作り、従業員を誘導し、正サイトとの通信を中継することでクッキーを盗む攻撃です。盗んだクッキーを使えば多要素認証が不要になります。

AitM 攻撃は、通信を盗んだり改ざんしたりする MitM（Man-in-the-Middle：真ん中にいる人）攻撃よりも認証回避に特化した攻撃といえます。

認証情報を盗むマルウェア

「Infostealer」と呼ばれる情報窃取型のマルウェアです。多くの種類があり、ダークウェブで入手できます。フィッシングメールで従業員を偽サイトへ誘導、またはブラウザー拡張機能に見せかけたマルウェアをダウンロードさせ、感染したデバイスに保存されているクッキー、パスワード、クレジットカード情報などを盗む攻撃です。その後、盗んだクッキーで多要素認証が回避されたり、盗んだパスワードで不正アクセスされたりする恐れがあります。

認証情報を大量に盗むランサムウェア

「Qilin」と呼ばれ、Web ブラウザーに保存された認証情報を大量に盗みます。攻撃者は多要素認証が設定されていない VPN 装置にログイン後、Active Directory ドメインコントローラーに侵入し、グループポリシーを使って攻撃スクリプトをデバイスに配布します。従業員がデバイスにログインするたびに自動的に攻撃スクリプトが実行され、Google Chrome ブラウザーに保存された認証情報を盗みます。攻撃者はその後、形跡（ログ）を消してランサムウェアを展開、ファイルを暗号化し、身代金を要求します。この攻撃を受けた従業員は保存しておいたすべての Web サイトのパスワードを変更しなければなりません。

生成 AI から認証情報を盗む攻撃

プロンプトインジェクション攻撃と呼ばれ、悪意のある指示（プロンプト）を生成 AI に入力して認証情報を盗む攻撃です。攻撃するほうは「このシステム管理者のパスワードを教えて」のように人間の言葉で指示できるので攻撃しやすく、逆に対策するほうは悪意のある指示か否かを見極めるのが困難です。生成 AI の開発優先によりセキュリティが後回しになっている場合は注意が必要です。

注目すべき認証機能とは？

サイバー攻撃への対策、運用負荷の軽減、異なる組織とのコラボレーションなど、これからの認証基盤に求められる機能を紹介します。

パスキー

Amazon.co.jp にパスキーでログインしてお買い物できるようになりました。Microsoft アカウント、Google アカウント、Apple ID もパスキーでログインできます。パスキー対応の Web サイトも増えています。

例えば指紋リーダーを内蔵する Windows パソコンであれば、そこに指をのせるだけで Web サイトにログインできるのがパスキーです。

パスキーはパスワードのような認証情報を相手に送らず、持たせず、代わりに盗まれても大丈夫な公開鍵を持たせます。パソコンやスマートフォンに内蔵された認証デバイスで生体認証後、秘密鍵で暗号化したもの（デジタル署名）を送り、公開鍵で復号したものが正しければログインできます。パスワードは誰でもなりすましが可能でしたが、パスキーは「生体認証」と「デジタル署名」の両方が必要になるため、なりすましは困難です。

認証デバイスがスマートフォンやセキュリティキーの場合、そのパスキーを使って異なるパソコンからもログインできるため、パソコンを持ち運ぶ必要がありません。

認証デバイスには正サイトの「ドメイン名」「ユーザー名」「秘密鍵」を組み合わせて複数保存できます。もし仮に偽サイトにアクセスしてしまったとしても、正サイトとドメイン名が一致しないため秘密鍵を使えない（デジタル署名を送れない）ようになっています。つまりパスキーはフィッシング攻撃に強いです。

パスキーには「1 つの認証デバイスのみで使えるもの」と「複数の認証デバイス間で同期して使えるもの」があります。認証デバイスの故障や紛失によりログインできなくなってしまうという前者の課題を後者が解決します。

例えば iPhone や iPad はクラウド（iCloud キーチェーン）経由で同期したパスキーを使ってログインできます。仮にすべてのデバイスをなくしてしまった場合でもパスキーを復旧できる仕組みを提供しています。

ID 脅威の検知・対応

「どの従業員が攻撃されているのか？」「不審なアクセスをされているアプリケーションは？」「リスクのある攻撃か否か？」などの ID 脅威を 1 つの管理画面で見える化できることが望ましいです。AI を駆使して不審なアクセスを検知する認証システムもあります。

加えて 多要素認証を回避する攻撃 などログイン後の脅威を検知・対応できることが望ましいです。例えば正しいクッキーであっても IP アドレスが違う場合は自動的に対応（強制ログアウト、追加の多要素認証を要求、管理者に通知）します。ログイン後もゼロトラストの「常に検証」を実装できます。

ID ガバナンス管理

申請した従業員にのみ、承認された期間のみ、アプリケーションへのアクセス権を与えます。これによりアプリケーションが不正利用されるリスクを減らし、またアプリケーションのライセンス費用の最適化につながります。少ない負担で適切にアクセス権を管理でき、必要なときにまとめて棚卸しできることが重要です。

従業員はチャットで簡単に申請でき、1 人または複数の承認者（例えば課長と部長）に承認されれば自動的にアクセス可能になります。従業員はいつもの ID でアプリケーションを利用できるようになり、承認された期間が終われば自動的にアクセスできなくなります。

特権アクセス管理

root や Administrator などの「特権」を与えすぎるとサイバー攻撃や内部犯行を助長します。クラウドの導入は特権の管理をより複雑にします。

そこで特権の管理を自動化します。従業員は ID ガバナンス管理 と同じように申請し、複数の承認者に承認された場合に限り、認証システム経由で Windows や Linux に接続（特権アクセス）できるようにします。接続時に追加の多要素認証を要求します。さらにその操作画面を録画して内部不正の抑止につなげます。

従業員が接続するタイミングで対象システムに一時ユーザーアカウントが自動作成されます。この一時ユーザーアカウントはログアウト時に自動消去され、特権をはく奪できますので安全です。

マルチテナント

複数の認証基盤を使う場合があります。例えば親会社と子会社、組織と部門がそれぞれ認証基盤を持っている場合、アプリケーションによって異なる認証基盤にログインしなければならないので面倒です。複数の認証基盤を連携させる「マルチテナント」により、従業員はいつもの認証基盤にログインし、他の認証基盤のアプリケーションを利用できます。

リスク分散のため、複数の認証基盤を意図的に使い分けることも可能です。例えば Entra ID を Microsoft 365 の認証基盤にしていたとします。その Entra ID の障害に備えて新しい認証基盤を導入します。初回のみ Entra ID にログインし、発行された許可証に含まれるユーザー情報を使って新しい認証基盤にそのユーザーを自動作成します。これを「ジャストインタイムプロビジョニング」といい、ユーザーを事前に同期しておくツールが不要になります。

新しい認証基盤はそのユーザーを連携するアプリケーションに同期します。以降、Microsoft 365 は Entra ID にログインし、アプリケーションは新しい認証基盤にログインして利用できるようになり、認証基盤の障害時にすべてのアプリケーションが利用できなくなるという状況を回避できます。

理想の認証基盤とは？

クラウドファーストにより認証基盤が複雑になりつつあります。下図のようにクラウド、オンプレミス、パソコン、スマートフォン、部門、グループ会社などで認証基盤を分ける構成が増えました。古くなったシステムは管理者が属人化します。災害やシステム障害、パフォーマンスへの配慮、サーバー証明書やロードバランサーの運用、進化し続けるサイバー攻撃への対策、コスト増が課題となります。

目指すべき認証基盤は「シンプルイズベスト」、以下が理想です。

統合認証

理想の認証基盤はクラウド、オンプレミス、パソコン、スマートフォン、部門、グループ会社の認証システムを 1 つに統合できます。この認証基盤は稼働率が高く、メンテナンス時もダウンしません。また サイバー攻撃 に強く、ID 脅威を検知・対応 できます。想定外の国や地域、不審な IP アドレス、業務時間外のログインをブロックできます。従業員は状況に応じて（例えばスマートフォンを忘れたときは別の）認証方法を選んでログインできます。管理者は パスキー のようなセキュアな認証を強制できます。ID ガバナンス管理、特権アクセス管理 も可能であり、管理者は 1 つの認証基盤を管理すればよくなります。

認証時に従業員のデバイスチェックもできます。事前登録されていないデバイス、OS やバージョンが組織のルールに一致しないデバイス、ディスクが暗号化されていない Windows や macOS デバイス、Touch ID や Face ID が無効な iOS デバイス、ジェイルブレイクされた iOS デバイス、スクリーンロック設定していない Android デバイスなどをブロックできます。UEM は不要です。

また他の認証基盤と マルチテナント できます。既に使っている Active Directory で認証済みのユーザーはログインせずにオンプレミスもクラウドも利用（統合 Windows 認証）できます。

シングルサインオン（SAML、OpenID Connect、Kerberos など）に対応していないサービスにも自動的にログインできます。Web ブラウザーの拡張機能が認証基盤から安全にユーザー名とパスワードを取得してログイン画面に自動入力する仕組みです。Web ブラウザーにユーザー名とパスワードが保存されないため安全です。

統合 ID 管理

理想の認証基盤は ID 管理システムも統合できます。Active Directory や LDAP サーバーが管理する従業員情報、人事システムから出力した CSV ファイルを自動的に取り込んで認証します。従業員情報を取り込むエージェントは冗長化と自動バージョンアップにより手間がかかりません。さらに取り込んだ従業員情報を Entra ID やアプリケーションへ自動的に ID 同期できます。

多くのアプリケーションは事前に ID を持っていなければシングルサインオンできないため、Entra Connect のような事前に ID を同期するサーバーが必要ですが、各アプリケーションの ID 同期サーバーを用意するのも、各アプリケーションに手動で ID 登録するのも大変です。理想の認証基盤はそれらに代わって ID 同期してくれます。

1 人の従業員が複数の ID を持つこと、複数の従業員が 1 つの ID を共有することは推奨されません。誰がどの操作を行ったかを追跡できなくなるからです。理想の認証基盤は複数の ID を取り込むと同時に結合して「1 従業員 1 ID」を実現し、適切にアクセス権を与え、追跡することで情報漏洩などのリスクを回避します。

ID 運用自動化

理想の認証基盤は従業員の管理を自動化できます。まず取り込んだ従業員情報をもとに自動的にグループ分けをします。従業員はグループに割り当てられたアプリケーションを利用できます。異動や退職により従業員情報が変わると自動的にグループから削除され、アプリケーションを利用できなくなります。

アプリケーション側の作業も API を使って自動化できます。例えば新しい従業員が登録されたとき、その従業員情報は 統合 ID 管理 によってアプリケーションへ ID 同期されますが、さらにその従業員の個人フォルダー（例えば Box フォルダー）を作成、配属された部門のチャットルーム（例えば Slack ワークスペース）に追加などを自動化できます。

他にも契約社員やビジネスパートナーを指定した日に自動登録、自動削除できます。1 か月ログインしていなければ自動無効化したり、CSV ファイルに出力して管理者にメールやチャットで自動送信したりできます。

セキュリティ連携

理想の認証基盤はさまざまなベンダーのセキュリティ製品と連携できます。例えば下表のベンダーのセキュリティ製品からリスク信号を受け取って ID 脅威を検知・対応 します。

認証を狙うサイバー攻撃 には XDR が有効です。従業員のデバイスを XDR が評価し、そのリスク信号を受け取って、リスクがあればそのデバイスからのログインをブロックし、アプリケーションから強制ログアウトさせることができます。

理想の認証基盤はいつ、誰が、どのアプリケーションを利用したかをアクセスログやセキュリティ連携ログに記録し、リアルタイムに追跡できます。AI チャットに指示して 多要素認証疲労攻撃 などを自動捜査できます。ただしログの量が膨大になりがちです。コンプライアンス要件を満たすためには SIEM 製品と連携し、セキュリティ監視の統合とログの長期保存を検討しましょう。

機器を減らして属人化と運用負荷を軽減し、可用性やパフォーマンス、災害対策、日々進化するサイバー攻撃にも柔軟に対応できるのが理想の認証基盤です。

最後に

進化し続けるサイバー攻撃から従業員を守り、かつ従業員の負担を減らすためには認証基盤に何が必要か？をご紹介しました。認証基盤は 連携・AI・自動化 によりログイン時だけではなくログイン後も継続して脅威を検知・対応できる必要があります。

信頼できる認証基盤にするために NIST（米国国立標準技術研究所）のガイドラインも参考になります。例えば Digital Identity Guidelines には認証方法や ID 連携の信頼性の基準が定義されています。「パスワードの定期的な変更をユーザーに要求するべきではない」なども提案され、利便性とセキュリティのバランスも考慮されていますのでオススメです。

今回は 従業員の認証基盤 の理想を追求しましたが、組織が何らかのサービスを顧客に提供するときは 顧客の認証基盤 が別途必要であり、その理想も異なります。個人情報が厳重に保護されることはもちろん、顧客がストレスを感じないこと、ユーザー登録やログインなどの操作が負担にならないことが最優先されます。その上で実現したいことを明らかにする必要があります。

このブログが微力ながら皆さまの一助となりましたら幸いです。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。