特権IDの管理が重要な理由
小川暁央氏：みなさん、こんにちは。NTTテクノクロスの小川と申します。このセッションでは、ゼロトラストの成功には特権ID管理基盤の適用が肝になるということをお話しさせていただきます。
ポイントは3つです。「ゼロトラストにおける特権ID管理の重要性」「ゼロトラストにおけるセキュリティ基盤としての特権ID管理の役割」、そして最後に「特権ID管理基盤を導入するための5つのステップ」をお話ししていきます。
さっそく、ゼロトラストにおける特権ID管理の重要性からお話しします。「クラウドの利用拡大」「リモートワークの普及」「デバイスの多様化」「DevOps・自動化」など、企業を取り巻くIT環境は複雑になっています。
IT環境の変化に伴い、セキュリティの境界も変化しています。これまでのセキュリティはネットワークを内と外に分け、その境界を防御する「境界防御」が中心でした。しかし、クラウドの利用などで重要な情報資産がネットワークの境界の外に広がり、境界防御だけではセキュリティを担保することが困難になっています。
これからのセキュリティは内と外に分けてセキュリティを作るのではなく、データやサービスへのアクセス制御を可能な限り細分化して、不正アクセスを防御する、「ゼロトラスト」の考え方でセキュリティを作っていくかたちになります。
その際に新たなセキュリティ境界となるのがIDですが、特権IDと一般IDの2種類があります。
特に強い権限を持つ特権IDは、究極の攻撃対象となります。近年は人間以外のマシンやクラウドなども特権IDを使うため、特権IDがあちこちに埋め込まれ分散しています。これら特権IDの侵害は、データ漏洩やシステム破壊などのサイバー攻撃の原因となり、ビジネスへの影響が大きいため、優先的な対処が必要となっています。
ゼロトラストの3つのポイント
続いて、ゼロトラストにおけるセキュリティ基盤としての特権ID管理の役割についてお話しします。まずゼロトラストという言葉の意識合わせをしたいと思います。
「ネットワークが侵害されている場合であっても、情報システムやサービスにおいて、各リクエストが正確かつ最小の権限となるようにアクセス判断する際の不確実性を最小化するために設計された概念とアイデアの集合体のことである」と定義されています。
定義だけを見てもよくわからないので、ポイントを3つに絞ってお話しします。
1つ目は、ゼロトラストの目標はデータやサービスへの不正アクセスを防止することなので、「アクセス制御を可能な限り細分化」します。2つ目は、必要な技術やどのような実装をするかに関して、まだ「かなり曖昧」です。3つ目は、「概念とアイデアの集合体」であって、組織によってシステム構成が異なるため、「単一のアーキテクチャにはなりません」。
こういった点を踏まえながら、実際にゼロトラストのシステム構成を画にしたものが、こちらのスライドです。
左側のデバイスやユーザが、サーバやデータベースなどのリソースにアクセスする際の認証・認可に関して、ポリシー決定／実施ポイントを必ず通過するように設計します。
ポリシー実施ポイントでは、アクセスを許可するかどうかを、下に書いたデータソースと連携して動的に決定していきます。この時、アクセス許可を判断するポリシー決定ポイントが、それぞれのデータソースと連携して情報を取り入れる必要が出てきます。
BtoB、エンタープライズの世界ではあまり実装がありませんが、Googleなどの認証ではよく使われています。例えばふだん使っていないデバイスから新たにアクセスする時に、追加の認証が求められるなどですね。そういったユーザやデバイスの動きに応じて、動的に認証を強化するような動きをとっていきます。
「人間以外」が使う特権IDの管理
先ほどの論理コンポーネントに、特権ID管理を適用した例がこちらです。
見方は一緒で、左側のデバイスやユーザがリソースにアクセスする際、ポリシー決定／実施ポイントを通過したあと、特権ID管理基盤を通過する流れになります。特権ID管理基盤では、アクセスの細分化は事前の申請・承認に基づいて行われ、アクセス制御は「ゼロ特権」と「一時的な特権IDの貸し出し」で行われます。
リソースへのアクセスはすべて監視され、承認されていない不正アクセスはすべて検出されます。さらに特権ID管理基盤では、すべてのセッションを記録することができます。
先ほどの例は人間が使うケースでしたが、最近は人間以外が使う特権ID管理も重要になっています。俗にいう埋め込みパスワード問題です。
例えばDevOps、CI/CDパイプラインによる開発です。高度な自動化によりコストを抑え、生産性を高められるメリットがあるので最近普及していますが、それぞれで使用されるコードやリポジトリ、ツール、クラウドで多くの特権IDが埋め込まれています。これらが管理されていないと攻撃のリスクが大きくなります。
特権ID管理基盤にはセキュリティのハブの役割があります。
人間・人間以外の特権アクセスをすべて監視する特権ID基盤を組織に適用することで、デジタルトランスフォーメーション時代のセキュリティを高めていくことができます。
特権ID管理の5つの適用ステップ
ここからは、ゼロトラスト実現に向けた特権ID管理の適用ステップについてお話ししていきます。特権ID管理基盤の適用は段階的で、かつ長期的な計画になります。まず現状を把握していただくことが大切ですので、みなさんがどの段階にあって、今後どのステップまで引き上げていくかの参考にしていただければと思います。
こちらの表に5つのステップを記載しました。
それぞれ簡単にお話ししていくと、まず最初のステップが、オンプレミスの特権ID管理です。こちらはオンプレミスにあるOS、データベース、アプリケーションなどの特権ID管理をするステップになります。続いてステップ2が、クラウドの特権ID管理ですね。ステップ1のオンプレミスを、クラウドまで適用範囲を広げたものになります。
ステップ3はワークスタイルの変化によって特権アクセスがリモートから行われるようになりましたが、外部のベンダーなどによるリモートからの特権アクセスに対する対策を行う部分です。
ステップ4はさらに先進的なもので、常時アクセス可能な特権IDを排除するというもの。最後のステップ5は人間以外への特権ID管理で、コードや自動化ツールに埋め込まれた特権IDに対して、特権ID管理基盤を適用していくもの。
ゼロトラスト実現に向けた特権ID管理の適用は、この5つのステップで考えていただければと思います。次のスライド以降でそれぞれのポイントを簡単にお話ししていきます。
リモートでの特権アクセスを実現する際の課題
まず特権ID管理の基本になります。オンプレミスの特権ID管理はゼロトラストを実現するための最初の一歩です。特権ID管理の管理・利用・点検の3つの運用管理が基本になります。
特権IDの管理をする時は、「特権IDを」「誰が」「使うのか」を1、2、3の運用レベルで見える化します。特権を許可に基づき一時的に使わせて、アクセスログと操作ログを記録して点検するという考え方です。ゼロトラストにおいても、特権ID管理の基本はこれまでと同じになります。こちらを基本に考えていただければと思います。
ステップ2では、これをクラウドにまで適用していきます。ステップ1との違いは2点です。
1つ目が、クラウド事業者さんとみなさんとで特権を共有することです。責任を共有するかたちになりますので、どこまでを自分たちが管理して、どこからがクラウド事業者が管理するのかを整理して、自分たちが管理しなければいけない特権をしっかり管理していただければと思います。
2つ目は、クラウド自体に特権IDがありますので、オンプレミスにはなかったクラウドの特権IDを管理することです。こういったところを漏れずに行っていただければと思います。
続いて、ステップ3のリモート特権アクセスを実現する際の課題です。
特権IDを使った作業は特殊な業務で、従来はセキュリティルームなど、特別な物理セキュリティを施した部屋で実装するのが一般的でした。ワークスタイルの変化によって、リモートワークでこれらの物理セキュリティをどのように再現するのかが課題になります。
問題となるセキュリティ対策は、「特権ユーザの本人確認」「リモート端末のセキュリティ対策」「不正操作の監視」の3つです。
これら3つの課題の解決方法を、こちらのスライドに載せています。
リモートワークにおける特権作業は、リモート端末とリソースのアクセスを中継する踏み台端末にアクセスを統合し、踏み台端末に対する安全なリモートアクセスと、踏み台端末のセキュリティ対策で実現できます。次のスライドの構成例を見ていただくのがわかりやすいと思います。
こちらが先ほどお話ししたものを画にしたものです。左側のリモートアクセス環境からリソースに対してアクセスする際に、踏み台サーバを経由するようにデザインしていただきます。
「ゼロ特権」の実現に必要な「一時的な特権貸出」
続いてステップ4の「ゼロ特権の実現」です。ゼロトラストにおける特権ID管理の役割は、特権アクセスの細分化です。ゼロ特権と一時的な特権IDの貸し出しによって実現できます。
ゼロトラストでは、フルコントロールを持つ特権IDが存在すること自体がリスクとなります。特権IDの存在は「過度な権限を持ったアカウントが誰でも使える状態」や「誰が使っているか把握できない状態」を作るため、ゼロトラストの考え方にそもそも反しています。
常時利用できる特権を排除した状態の「ゼロ特権」を実現すること、もしくは「一時的な特権IDの貸し出し」が必要になります。ゼロ特権の実現が難しい場合は、常時存在する特権IDに対して一時的な特権IDの貸し出しのみでリスクを軽減します。
こちらのスライドはゼロ特権の実装方法です。
既存の特権IDを排除できるかできないかでアプローチが変わります。既存の特権IDが排除できる場合は、「特権作業をする際に都度新しい特権を一時的に作って貸し出す」か、「非特権、一般の権限のIDに対して一時的に強い権限を付与して作業させる」といったアプローチがあります。
OSなどがそうですが、既存の特権IDの排除が難しい場合は、既存の特権IDを一時的に貸し出すといったアプローチが可能になります。こういったものを特権ID管理ツールを使って実装いただくことが必要です。
最後は、人間以外の特権ID管理のステップ5です。まず人間以外が使う、Webサービスやプログラム、ロボットなどの特権IDを把握して、それらのクラウドやロボットなどに対して特権IDの適用を行います。
セキュリティ運用の自動化
こちらのスライドには、人間以外への特権ID管理の実装方法例を記載しました。
基本的に人間がやる場合と同じです。スクリプトの例になりますが、スクリプト内にパスワードを直接埋め込むのではなくて、iDoperationから常に最新のパスワードを取得していただくかたちになっています。こうすることで、認証情報をハードコードせず、セキュアに、プログラムなど人間以外に提供することが可能になります。
こういったことを進めていくと、セキュリティ運用の自動化も可能になります。ちょっと複雑になりますが、こちらのスライドで簡単に説明します。
左側に特権のユーザ、右側にリソースがあります。よくある例としてターゲットからアラートを受信しています。受信したアラートをITSMなどのワークフローに連携して、例えば人間が判断する必要がある場合は作業の承認をすると、チケットが発行されてロボットが作業を実施します。
その際の特権を、自動的に特権ID管理ツールから取得して作業する。作業が終わったあとの特権IDは自動的にランダムなものに変更され、一時的なロボットへのパスワード貸し出しが行われます。一連の操作ログはすべて特権ID管理ツールに記録されますので、操作内容や定期的なアクセスレポートの点検などを実現できるようになります。
iDoperationによる3つの運用管理
最後に、iDoperationを使った特権ID管理のデモを簡単に見ていただこうと思います。iDoperationは、特権ID管理ツールの分野で8年連続シェアNo.1の評価をいただいており、エンタープライズを中心に多くのお客さまに利用いただいているツールになります。
iDoperationは、Administratorやroot、AWSのIAMユーザなどの特権IDを誰が使うのかを適正に管理する製品で、先ほどご紹介した特権ID管理のベストプラクティスの3つの運用管理が実現できます。具体的にはこちらの「管理・利用・点検」です。
「管理」で特権IDを誰が使えるのかを見える化し、見える化した特権IDを承認に基づき一時的に「利用」させます。最後にアクセスログと操作ログを記録して、特権iDの利用を「点検」することができます。
iDoperationはクラウド、OS、データベース、ディレクトリ、仮想化のソフトウェア、そしてAWSなど組織内にあるすべての特権IDを標準で取り込み、可視化します。
それらiDoperationで管理する特権IDを、Webのワークフローを使って、承認に基づき一時的に貸し出すことができるようになっています。
ここからは実際のデモをご覧いただきます。特権IDを使うユーザは、iDoperationのWebコンソールにアクセスし、まずユーザIDとパスワードで認証します。
必要に応じて、認証コードで追加の認証をかけることもできます。
iDoperationにログインすると、その方に関連があるお知らせや利用状況が出てきます。特権IDを使って作業する際は、申請名や利用期間などを入力する特権IDの利用申請を行っていただきます。ここでは「会計システムのストレージ拡張作業」で、作業日時を指定し、必要に応じて利用目的や作業内容をWebフォームに入力します。
作業内容などについては、添付ファイルなどがある場合はそちらも添付できるようになっています。
そして、この作業で使う特権IDを選んでいただきます。特権IDの指定の仕方はいくつかありますが、今回見ていただくのは事前に管理者の方が作業ごとの特権IDをグルーピングした「申請プリセット」を使った申請例です。
今回はストレージのメンテナンス作業をするので、ストレージメンテナンス用のアカウントを選んでいただきますと、この作業に関連した特権IDが選択されます。
これで申請していただきますと、事前に設定された承認者の方に承認依頼のメールが飛び、その方が承認すると特権IDの貸し出しが行われるかたちになっています。
iDoperationで管理する特権IDの使い方
それでは承認された後に、どのように特権IDを使うのかを見ていただこうと思います。こちらは特権ユーザの方のパソコンだと思っていただければと思います。Windowsにログオンしていただき、例えばAWSであればブラウザを起動したり、リモートデスクトップを起動してWindows Serverにアクセスしたりします。
iDoperationを使う時は先ほどと同様にブラウザを使って、iDoperationのWebコンソールにログインしていただきます。認証を終わらせた後に実際に作業をしていただくかたちになります。
iDoperationにログインしていただくと、先ほど同様にダッシュボードが出てきますが、今度は特権利用というメニューを選んでいただきますと、今私が使えるサーバと権限の一覧が出てきます。今回の例であれば、まずAWSのマネジメントコンソールに接続して作業したいと思います。
接続ボタンを押すと接続の確認が出ますので、OKを押すと、AWSマネジメントコンソールにシングルサインオンでログインするかたちになります。
作業が終わった後は、再びiDoperationのWebコンソールから、今度はWindows Serverにつないでみたいと思います。
会計サーバを選んで接続を押し、確認画面でOKを押すと、特権IDの貸し出しが行われてローカルのリモートデスクトップのアプリが起動します。
利用者である私には特権IDのパスワードを教えていないので、iDoperationを使わないと各システムに特権アクセスができないのがポイントです。
自動監査による不正アクセスの検出
iDoperationでは、このように特権ユーザが特権アクセスしている裏で、自動的にアクセスログを集めて監査をします。
集めたアクセスログと申請の情報を突き合わせて点検し、申請が出ていないアクセスを不正アクセスとして発見することができるようになっています。監査レポートを使っていただくと、不正アクセスを簡単に見ていただくことができます。
こちらがiDoperationで出力した監査レポートになります。
点検のサマリーは上部に一覧で表示されます。何らかの理由で申請のない特権アクセスがあった場合は、異常が赤字で表示されます。見方は、緑の線を引いた部分がワークフローからの情報で、紫の線を引いた部分がサーバなどから取得したアクセスログ、赤い部分が点検結果になります。
上の2行が、何らかの理由で申請されずに使われたもので、このように赤字でアクセスログだけが表示されます。「動画を見る」を押すと、不正アクセスがあった際にどのような操作が行われたかを、視覚的に確認していただけます。
ということで、本日のまとめになります。
ゼロトラストにおいては、重要な情報資産にアクセスできる特権IDは究極の攻撃対象となるため、特権ID管理の適用を優先的に検討する必要があります。特権ID管理の5つの適用ステップを参考にしていただき、現状を見直し、できていない部分を早急に検討していただければと思います。
最後に、8年連続シェアNo.1の実績豊富なiDoperationを使っていただきますと、ゼロトラストで求められる特権ID管理の課題を解決することができます。iDoperationに関するご質問・ご相談に関しては、お気軽にお問い合わせいただければと思います。
ご清聴ありがとうございました。
