【Oktane25】セッション：非人間ID（NHI）をISPMで発見しOktaで管理する

①発見 (Discover)：ISPMによる非人間IDの可視化とリスク評価

デモセッションは、まず組織内に存在する無数のNHIを発見するプロセスから始まりました。ここで中心的な役割を果たすのが、ISPM（Identity Security Posture Management）です。

ISPMによる可視化とリスク評価

セッション上でISPM管理コンソールのNHI画面を開くと、そこには3,600を超えるIDがリストアップされ、サービスアカウント、APIトークン、アクセスキーなどが含まれていることが示されました。ISPMはAWS、Google、Salesforceといった様々なクラウドプラットフォームとAPI連携することで、組織内のID全体を可視化しています。

単なる可視化に留まらず、NHI毎にのリスクを自動で分析し、提示してくれます。デモでは、以下のような非常に危険なサービスアカウントが例として挙げられました。

• 権限: スーパー管理者

• 最終利用日: 1年前

• パスワード最終変更日: 1年前

このように、長期間利用されていないにもかかわらず最高権限を持ち、パスワードも変更されていない「休眠アカウント」は、侵害された場合の影響が計り知れません。ISPMは、このような組織のセキュリティホールを明らかにしてくれます。

リスク検知後の通知と自動化プロセス

セッションでは、まずリスクの存在を関係者に迅速に知らせ、対応を促すための自動化の仕組みが二つ紹介されました。

1. 標準連携によるシンプルな通知
簡単な設定で実現できる方法として、Oktaの標準連携機能（Outbound Integrations）が紹介されました。 ISPMがリスクを検知した際に、ServiceNowやJiraにシンプルなチケットを自動で起票したり、Slackの特定チャンネルに固定のメッセージを通知したりできます。これにより、管理者は普段利用しているツール上で、リスクの発生にいち早く気づくことが可能になります。

2. Okta Workflowsによる自動化
Workflowsでは、ISPMがリスクを検知したイベントをWebhookで取得できるため、標準連携機能以外にも高度に自動化を構築することが可能です。
様々なユースケースに応じたフローのテンプレートがGit Hubで公開されており、すぐに利用を開始することができます。

https://github.com/okta/workflows-templates/tree/master/workflows/identity_security_posture_management

このように、ISPMはリスクを「発見」するだけでなく、その後のアクションに繋げるための強力な自動化機能を備えている点が、セッションでは強調されていました。

「①Discover（発見）」のパートで行われた質疑応答をQ&A形式でまとめます。

Q1. ISPMは、GoogleやGitHubなど様々なシステムからサービスアカウントを発見していましたが、これはどのように行っているのですか？

A. はい、ISPMは各システム（プラットフォーム）とAPI連携をすることで、アカウント情報を収集し、環境内で何が起きているかを把握しています。この時点での役割は、あくまでアカウントを「発見」し、リスクを「可視化」することです。

Q2. 発見したアカウントが、人間のユーザーアカウントなのか、サービスアカウントのような非人間ID（NHI）なのかを、ISPMはどのように判別しているのですか？

A. スピーカーもエンジニアリングチームに確認したそうですが、AIによる機械学習を活用しているとのことです。ログイン時の振る舞いやアクセスのパターンなどを分析し、そのIDが人間か非人間かを自動で判別しています。

②保護・修正 (Remediate)：OPAによるサービスアカウントの保護・修正

ISPMによってリスクの高い非人間ID（NHI）を「発見」した次のステップは、そのリスクを「保護・修正」することです。セッションでは、Salesforce上で発見されたサービスアカウントを例として、OPA（Okta Privileged Access）を用いた具体的な保護プロセスが実演されました。

OPAによるサービスアカウントの保護プロセス

デモでは、以下の手順でサービスアカウントの厳格な管理を実現していました。

1. アカウントの保管（Vaulting）
対象となるSalesforce上のサービスアカウントをOktaのディレクトリに登録し、OPAの管理下に置きます。これにより、認証情報が一元的に管理され、誰が・いつ・何にアクセスしたかという監査証跡も記録されるようになります。

2. ポリシーによる厳格なアクセス制御
このアカウントに対してOPAでアクセスポリシーを設定します。デモでは、以下の3つのポリシーが適用されました。※時間の関係上ポリシーの詳細は説明されていません。

• パスワードの自動ローテーション
  アカウントが使用されるたびに、パスワードを自動でリセットするポリシーです。これにより、認証情報が漏洩するリスクを大幅に低減します。

• フィッシング耐性のあるMFAの要求
  サービスアカウント（NHI）を利用するユーザーに対して、Okta FastPassのようなフィッシング耐性のある認証要素を必須とします。

• 承認ワークフローの導入
  人間がこのサービスアカウントを一時利用する際に、承認者による承認を必須とする多段階の承認フローを構築します。

実際の利用フロー

これらのポリシーを設定した結果、管理者（人間）がこのサービスアカウントを利用する際のフローは以下のようになります。

1. 管理者がOPAのダッシュボードから、Salesforceサービスアカウントの利用を正当な理由を添えてリクエストします。

2. リクエストが承認者に通知され、承認者が内容を確認して承認します。

3. 承認後、元のユーザーはフィッシング耐性のあるMFA（デモではFastPass）で本人認証を行います。

4. すべてのプロセスが完了して初めて、管理者はサービスアカウントの認証情報 (パスワード等) を閲覧・利用できるようになります。

このように、OPAを活用することで、サービスアカウントのような強力な権限を持つIDに対して、厳格なアクセス制御と監査証跡の取得を両立できることができます。また、サービスアカウントのパスワードは誰も直接的に知らない状態を作ることができます。

③統制 (Governance：OIGによる継続的な権限の見直しと統制

アカウントを一度保護して終わりではありません。時間が経つにつれて、人事異動やプロジェクトの終了などにより、本来は不要なはずの権限を持ち続けてしまうユーザーが現れることがあります。スピーカーは、こうした「IDのスプロール化（無秩序な増殖）」を防ぐための、継続的な「統制」のプロセスが不可欠であると強調しました。

この役割を担うのが、OIG（Okta Identity Governance）です。

OIGによるアクセス認証キャンペーンの自動化

セッションのデモでは、OPAでサービスアカウントへのアクセス権を持つ特権グループに、新たにユーザーを追加するシナリオが実演されました。

1. 管理者がOktaのUniversal Directoryで、特権グループにユーザーを追加します。

2. この「グループへのメンバー追加」というイベントをトリガーとして、OIGが自動的にアクセス認証キャンペーンを生成します。

3. グループの所有者（マネージャーなど）のもとに、「グループメンバーのアクセス権は適切かレビューしてください」というタスクが発行されます。

4. 所有者は、各メンバー（既存のメンバーと、新しく追加されたユーザー）が、引き続きこの特権グループに所属する必要があるかを一人ひとり承認または否認します。

「多層防御」という考え方

このデモに対し、会場からは「グループへの参加を承認するプロセス（③で行う承認プロセス）と、実際にアカウントを利用する際に承認するプロセス（②で行う承認プロセス）があり、二重になっているのでは？」という質問がありました。

スピーカーは、これを「多層防御」であると説明しました。この2つの承認プロセスは、目的とタイミングが異なる、重要な二重のチェック機構として働いています。

• 第1層：OIGによるアクセス認証（資格の棚卸し）
  これは、定期的に「そもそも誰がその特権を利用する資格を持つべきか」という資格そのものを見直すための、広範なガバナンス層です。

• 第2層：OPAによる承認ワークフロー（都度の利用許可）
  資格を持つ人が、特定の目的で「今まさにその特権を使いたい」と申請した際に、その都度の利用を許可するための、リアルタイムなアクセス制御層です。承認者は、以下のような画面でリクエストの内容を確認し、その妥当性を判断して承認または否認します。

このように、OIGを活用することで、非人間IDを利用できる可能性のあるユーザー群を常に最小限かつ最適な状態に保ち、継続的なセキュリティを確保できることが説明されました。

おわりに