COLUMN
多要素認証だけで十分?NTT東日本のゼロトラスト認証・認可を徹底解説
こんにちは!NTT東日本 セキュリティエンジニアのコーダイです。
ゼロトラストセキュリティコラムの7回目になります。
過去のコラムをまだご覧になっていない方は是非ご覧ください。
第1弾コラム:「NTT東日本で実際に導入しているゼロトラストセキュリティを徹底解説!」
第2弾コラム:「NTT東日本におけるゼロトラストセキュリティの設計と導入」
第3弾コラム:「NTT東日本でゼロトラストセキュリティの運用・監視をやってみた」
第4弾コラム:「NTT東日本でEntra ID・Intuneを活用してみた」
第5弾コラム:「NTT東日本でEntra ID・Intuneを活用してみた(モバイル編)」
第6弾コラム:「NTT東日本でMDEを活用してみた」
本コラムでは、近年重要となっている認証・認可についてNTT東日本で利用しているMicrosoft Entra IDにスポットを当ててご紹介いたします。
最後までお付き合いいただけますと幸いです。
1. 認証・認可とは
皆さまの中には、認証・認可という言葉について聞いたことがある方も多くいらっしゃるかと思います。しかし、その意味や重要性について正確に把握されているでしょうか。この章では、認証と認可について詳しく説明いたします。
1-1. 認証・認可の定義
認証・認可の言葉の定義についてご説明いたします。
認証 (Authentication) :
アカウント(ID)の真正性を確認することです。
本当にアカウントを所持している本人であるかを確認します。
例えば、インターネット上のサービスにIDとパスワードを入力してログインしたとします。パスワードは本人しか知りえないため、パスワードが正しいものということを確認することが認証と言えます。
認可 (Authorization):
アカウント(ID)がアクセス可能な範囲(権限)を制御することです。
例えば、人事システムについて考えてみます。人事担当者のアカウントでは社員の採用履歴にアクセスできますが、一般社員はアクセスできません。
認証も認可も何らかのシステムを利用する際には必ず必要な要素です。
認証・認可の具体例
1-2. 認証・認可が不適切だとどうなるか
認証が不適切な場合
認証は本人の真正性を確認するプロセスです。
認証が不適切だと、別の人が本人になりすましてシステムにアクセスできてしまいます。現実でも認証が不十分であったために発生した事例が多く発生しています。
【事例1】
別サイトやダークウェブなどからアカウント名、パスワードを不正に得た外部の攻撃者により、社内システムに不正ログインされた。結果、攻撃者が顧客情報を外部に漏えいしたほか、システム内の情報を暗号化し、数か月間使用不可とした。
【事例2】
顧客にサービスを提供するシステムに対して、海外のIPアドレスから多数のログインが試行された。結果、攻撃者が数千人のアカウントに不正にログインし、個人情報のほかクレジットカード情報の一部を不正に閲覧した。
上記2つの事例では、漏えいされた認証情報の悪用もしくは海外からの多数のログイン試行により、不正に認証を突破されました。また、これにより企業は個人情報の漏えいや業務に必要なシステムの停止といった大きな損害を被りました。
認可が不適切な場合
認可はアクセス可能な範囲を決めることです。
認可を適切に管理していないと、想定外の影響が発生する場合があります。
上記のような事例は実際に発生しています。
【事例】
ある大手通信教育会社で、必要がないのに顧客データベースへのアクセス権限を委託先システム開発者に付与していた。開発者はデータベースから数千万件の顧客情報を外部記録媒体にデータをコピーして社外へ流出させた。流出期間は約1年にもおよび、その間アクセス権限の見直しが定期的に行われていない状況であった。
上記の事例では、権限の適切な設定、およびライフサイクル管理が適切ではありませんでした。これにより、従業員の不正を許したことで、大きな影響をもたらしました。
1-3. 認証・認可は非常に重要
ここまで、下記のことをご説明いたしました。
- 認証はアカウント(ID)の真正性を確認し、認可はアクセス権限や操作権限を決めるもの
- 認証・認可が適切に管理されていないと企業活動に大きな損害をもたらす可能性がある
認証・認可は適切な管理が非常に重要なものであることがご理解いただけたかと思います。
2. NTT東日本ゼロトラストセキュリティの認証・認可
ここからは、NTT東日本で実際に使用しているゼロトラストセキュリティ環境での認証・認可の要件決定から実装までをご紹介いたします。
2-1. 要件の決定と基本設計
NTT東日本では、生産性を高めつつ、いつでもどこからでも快適に働けることを目的にゼロトラストセキュリティ環境を導入しました。
導入に至った経緯、要件については下記のコラムで詳しく説明しておりますのでご覧ください。
第1弾コラム:「NTT東日本で実際に導入しているゼロトラストセキュリティを徹底解説!」
【参考】NTT東日本ゼロトラストセキュリティ要件
セキュリティ要件1 | リモートから会社リソースへのセキュアなアクセス方法の確立 |
セキュリティ要件2 | 利便性の高いアプリケーションの利用促進とセキュリティの両立 |
セキュリティ要件3 | 情報漏えい対策を確保した上での、外部とのコラボレーション方法の確立 |
セキュリティ要件4 | 高度化するサイバー攻撃や内部不正の可視化とその対策 |
上記のセキュリティ要件すべてに認証・認可は関連していました。そこで、各要件に対応した認証・認可の基本方針を策定しました。
インターネット上では、多要素認証の導入を推奨するような記事は多くあるかと思います。しかし、これは認証の一側面に過ぎず、利便性や高度化するサイバー攻撃、内部不正への対策を考えると考慮すべきポイントは多く存在します。
# | 要件 | 認証基本方針 | 認可基本方針 |
---|---|---|---|
1 | リモートから会社リソースへのセキュアなアクセス方法の確立 | パスワードが漏えいしたとしても、対応できる多要素認証を採用する | - |
2 | 利便性の高いアプリケーションの利用促進とセキュリティの両立 | 複数のシステムに対して自動でシングルサインオン(以下、SSO)できる仕組みの導入 |
|
3 | 情報漏えい対策を確保した上で、外部とのコラボレーション方法の確立 | - | 他社ユーザーに対して、最小期間かつ最小範囲で会社情報へのアクセス権限を設定する |
4 | 高度化するサイバー攻撃や内部不正の可視化とその対策 | なりすましやサイバー攻撃を検知・ブロックできる仕組みの導入 | - |
【参考[補足]】
多要素認証といってもそのレベルにはいくつか種類があります。
米国立標準技術研究所(NIST)が米国の連邦政府機関向けに公開しているNIST SP 800-63という認証ガイドラインがあり、弊社ではこれを参考にしています。NTT東日本ゼロトラストセキュリティでは、サイバー攻撃への耐性やコストなどを考慮した結果AAL2相当認証の実装を方針としています。
認証レベルの定義
レベル | 条件概要 |
---|---|
AAL1 | 単一認証 |
AAL2 | 多要素認証が必要 ただし、各要素は異なる種類である必要がある(知識・所持・生体情報を組み合わせる必要がある) |
AAL3 | AAL2加えて、ハードウェアの認証要素およびなりすまし耐性がある認証要素が必要 |
参考: NIST Special Publication 800-63 Revision 3
多要素認証については下記の記事でも詳しく紹介しています。合わせてご覧ください。
多要素認証とは?二段階認証との違いやメリットデメリットまで解説
2-2. 機能の実装
ここからは、上記の基本方針を元にした実装についてご説明いたします。
実装においては、会社としてMicrosoft 365を導入していることもあり、SSO連携できるサービスも多く存在することからMicrosoft Entra ID(以下、Entra ID)というIDaaSサービスを利用することにしました。
2-2-1. 各種サービスアクセスの認証・認可機能の実装
各種サービスアクセスの認証・認可機能の実装状況
上記の図は、業務で利用するアプリへアクセスする際に行われる認証・認可フローを示しています。Microsoft Entra IDの「条件付きアクセス」を用いて実装しています。「条件付きアクセス」は他のMicrosoft 365製品と連携するため、連携箇所についても記載しています。
認証・認可部分で実施する具体的な設定内容は下記のとおりです。
認証部分:
- 各種サービスへサインインする際には多要素認証を要求する
- サインイン時、もしくはユーザーアカウント自体にリスクがある場合には、追加認証やパスワードリセットなどを要求しリスクを低減する
認可部分:
- 端末の状態、クライアントアプリの種類、ネットワークルート、サービスの組み合わせを要素とするアクセスパターンごとに認可条件を設定する
(こちらについては第5弾のコラムをご確認ください)
【参考】連携している各サービスとその機能
認証部分で連携する機能一覧
連携機能 (サービス名称) |
機能概要 |
---|---|
認証方法 (Microsoft Entra ID) |
多要素認証として使用する要素(認証アプリ、SMS認証など)を指定して多要素認証の強度を高める。 |
Identity Protection (Microsoft Entra ID) |
学習した定常時のサインイン情報との乖離、ダークウェブなどに掲載される情報などからサインインおよびユーザーアカウントのリスクを判定する。 |
パスワードリセット (Microsoft Entra ID) |
ユーザーが自らパスワードをリセットできる仕組みを提供し、攻撃時のリスク解消を図る。 |
認可部分で連携する機能一覧
連携機能 | 機能概要 |
---|---|
コンプライアンスポリシー (Microsoft Intune) |
端末の設定を評価する機能で、端末暗号化有無やウイルス対策ソフト有効有無などを条件として設定できる。 評価結果はEntra IDに連携されて、条件付きアクセスの条件として指定できる。 |
ネームドロケーション (Microsoft Entra ID) |
IPアドレスもしくは国をタグ付けする機能で、これを条件付きアクセスの条件に使用できる。 |
エンタプライズアプリケーション (Microsoft Entra ID) |
アプリケーション管理機能で、シングルサインオン(SSO)の設定などが可能である。条件付きアクセスの条件としても使用可能なため、認証の際に多様な条件が指定できるようになる。 |
セッション制御 (Microsoft Defender for Cloud Apps) |
アプリ使用時に操作制限(コピー&ペースト、ファイルダウンロードなどの禁止)を適用する機能である。 |
2-2-2. 認可(権限)管理機能の実装
① 特権管理
特権管理機能の実装
特権管理については、Entra IDのPrivileged Identity Management(以下、PIM)、エンタイトルメント管理を用いて実装しています。
一般社員への端末管理者権限の付与:
弊社では社員が利用する会社貸与端末に対して管理者権限を与えていません。
しかし、業務上の理由から管理者権限での操作を必要とする場面は少なくありません。例えば以下のような場面があります。
- 業務アプリをインストールに管理者権限が必要
- 端末の時刻が狂ってしまったので手動で同期したい
- 端末に固定IPアドレスを設定したい
- 不具合のあるドライバーを再インストールしたい
上記の要望の実現と必要最小限の権限付与という要件をPIMで実現しています。弊社ではオペレータがユーザーに対して端末の管理者権限を付与し、一定期間経過後に自動的に権限を削除する設定としています。
システム運用者への権限付与:
システム運用者はその性質から一般社員と比較して強い権限を持つため、権限付与範囲や異動時の削除対応が重要です。
弊社では、上記の機能を実現するためにエンタイトルメント管理という機能を用いて実装を行っています。
エンタイトルメント管理とはアクセス権限のライフサイクルを管理するものです。権限付与のフロー管理、定期的なレビュー、レビュー未実施時の権限はく奪の自動化などの機能を備えています。
上記の機能を用いて、具体的には下記の実装を行っています。
- 権限付与:
複数権限をまとめられる「アクセスパッケージ」を使用し、あらかじめ業務に必要な最小権限群をパッケージ化し承認制で権限を付与する - 権限レビュー:
権限の付与状況を定期的に確認できる「アクセスレビュー」を使用して設定した管理者に対して定期的に権限付与状況の監査を要求する
② 外部コラボレーション
弊社ではTeamsをコミュニケーションツールとして活用しており、部署やプロジェクトなど共通の作業を行うメンバーのグループであるTeamsのチームに社外のユーザーを招待する機能を実装することで、外部コラボレーションを実現しています。
これにより、社外のお客さまや協力会社との情報のやり取りが効率化できますが、一方で情報漏えいリスクがあります。
このリスクを軽減するために、システム運用者への権限付与同様、「エンタイトルメント管理」を活用しています。
- 権限付与:
「アクセスパッケージ」を用い、ゲストユーザーがアクセスするTeamsチームへのアクセス権限のみをパッケージ化して配信 - 権限レビュー:
「アクセスレビュー」を用い、設定した管理者に対して、定期的に権限付与状況の監査を要求し、アクセスが不要になったゲストユーザーの権限を削除する
ゲストユーザー権限管理機能の実装
3. 運用状況
ここからは実際の運用状況についてご紹介します。
3-1. セキュリティリスクへの対応
弊社は約5万人の社員が在籍し、ユーザーアカウントの数も多いことからサインイン時やアカウント自体に対するリスク事象は多く発生します。例えば、直近1か月でも約150件の不審なサインインをIdentity Protectionで検知しています。
このような調査・対応判断を1件ずつ行うと手間がかかります。また、調査に時間を要するとその間に被害が拡大するかもしれません。
そのため、弊社では、リスクレベルに応じて自動で一次対処を行う仕組みを条件付きアクセスで実装し、対処の迅速化と運用負荷の軽減に役立てています。
ここでは、その一例をご紹介します。
海外からのアクセス試行:
ある日、アメリカからAzure CLIというサービスに対して複数回サインイン試行が発生しました。発生時、Identity Protectionでは「通常とは異なるサインインプロパティ」というリスクを検出し、条件付きアクセスによりサインインを自動でブロックしました。さらに、ユーザーアカウントに対するリスクも高まったことから、自動的にパスワードリセットも実施しました。
ユーザーにもヒアリングを行いましたが、心当たりはないとのことでしたので、不正アクセスを試みていたことが判明しましたが、既に自動で一次対処が行われていたため大事には至りませんでした。
3-2. SSO連携サービスに対するアクセス制御設定
弊社では申請に基づきEntra IDと各種システムでSSO連携を行っています。SSO連携を行うと条件付きアクセスによるリスク判定、アクセスパターンに応じた認可条件の設定が可能です。
しかし、連携システムが増えていくと設定数が増えて管理が困難になることが予測されました。この問題を未然に防ぐために、弊社ではアクセスパターンごとに設定を作成し、そこにサービスを収容するという運用を行っています。
SSO連携システム認可条件のパターン分け
新サービス追加時には設定を新しく作成するのではなく、既存の設定の対象範囲にサービスを追加するのみとなります。実際、設定作業は数分もかからず完了できています。
4. まとめ
今回のコラムではNTT東日本ゼロトラストセキュリティの認証・認可についてご紹介させていただきました。
タイトル記載したように、認証・認可についてはよく言われる多要素認証以外にもさまざまなポイントがあることを理解いただけたかと思います。
NTT東日本では今までのノウハウを生かした制御ポリシー設計の支援もご提供しております。気になる方は是非ともご相談ください。
次回は、メールの制御・監視をテーマにMicrosoft Defender for Office365の活用についてのコラムを予定しております。
メールに関するセキュリティ対策に興味のある方は、ぜひご覧いただきたいと思います。
これからゼロトラストセキュリティの導入を考えているが、自分たちではやりきれない、何をしたらよいかわからないという皆さま、是非、NTT東日本へご相談ください!私たちのノウハウで皆さまの新しい働き方を全力サポートいたします!
今後の掲載予定コラム
- 経緯、要求定義について
- 設計、導入について
- 運用、監視について
- EntraID・Intune運用①
- EntraID・Intune運用②
- MDE運用 前回
- アカウント認証・認可 (IDaaS) 今回
- メール制御監視 次回
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。