皆様こんにちはこんばんは、Oktaneをこよなく愛するネクストモードのおはらふです
SSOやMFAで「表の玄関」はしっかり固めたけれど、「裏口」にパスワードを使ったサービスアカウントが残っている…、そんな心当たりはありませんか？
今回は、そんな非人間ID（Non-Human Identity：NHI）を、Oktaの各製品を組み合わせて発見から統制までエンドツーエンドで守るデモのセッションがありましたので、その様子をお届けしたいと思います
Oktane26、非人間ID（NHI）、ISPM、Identity Threat Protection、Okta Workflows、Okta Privileged Access、Okta Identity Governance、ゼロスタンディング特権
Paul O'Mahony, Staff Identity Security Engineer, Okta
ちなみにNHIというのは、サービスアカウントやAPIキー、BOTなど「人以外の何か」が使うIDのことです
人のIDに比べて管理の目が届きにくく、権限が強いまま放置されがちなのが課題とされています
セッションは会場への問いかけから始まりました
最後の質問で手が一本も挙がらず、「それが見たかった」と登壇者は満足していました
ここで述べた状態こそが「NHIの死角」であり、今回のデモではそれを次の流れで解消していくとのことです
最初に登場するのはOkta Identity Security Posture Management（ISPM）です
アイデンティティやセキュリティエンジニアにとって最大の死角は、日々管理しているIDではなく「存在を知らないシャドーID」とのこと
ISPMは環境全体を継続的に可視化し、管理外のID、MFAの未設定、古いパスワードなどのリスクをスキャンしてくれます
デモでは、ISPMがSalesforceテナントでクリティカルなアラートを検出していました
今回はSaaSのサービスアカウントにフォーカスしていますが、同じ考え方はNHI全体に適用できるそうです
検出されたアカウントは次のような状態でした
ここまで重なると単なる設定ミスではなく「パーフェクトストーム」だと表現していました
典型的な企業では、こうしたアカウントは退職者が作った忘れ去られたスプレッドシートの中にだけ存在し、ペネトレーションテストか、最悪の場合は攻撃者に見つかるまで誰も気づかないとのことです
「アクションのない可視化は、リスク管理台帳の一行が増えるだけ」とし、ISPMの画面からそのまま是正に移ります
ボタンをワンクリックするだけで、バックグラウンドでWorkflowsが動き、このアカウントをOPAにオンボードできます
では、是正が間に合う前に攻撃者が裏口アカウントを悪用したらどうなるのか？
デモでは事前にインシデントをシミュレートしていました
シナリオはこうです
退職者がパスワードのコピーを持ち出しており、表玄関はSSOが強制されていると知っているので、Salesforceのログイン画面に直接クレデンシャルを入力して裏口からアクセスした
従来のシステムでは手遅れになるまで気づけず、重要なアラートも大量のログに埋もれてしまいます
セキュリティチームはアラート疲れに苦しんでいるため、必要なのは「即時かつコンテキストを踏まえたアクション」だと述べていました
ここからWorkflowsの動きを順に見ていきます
まず、検知用のフローが通常の通信経路外（Out-of-band）のログインを捕捉し、異常な振る舞いとしてフラグを立て、是正用のフローを呼び出します
是正フローではまず対象アカウントを特定し、次の2点を確認します
結果は「どちらにも該当しない＝野良アカウント」
アカウントをリスク台帳に登録し、是正アクションへ進みます
ここで登壇者が補足していたのが、フロー内のIdentity Threat Protection（ITP）のアクションです
もしフェデレーションされたアカウントで、リスクが「高」と判定された場合は、ITP側で是正が行われます
デモ画面では、リスク「高」でセッション保護違反が検出されているものの、ステータスは監視モードでした
これを強制モードにすれば、Universal Logout、セッション終了、アプリへのアクセス拒否といった手段で対処できるとのことです
今回はフェデレーションされていないSalesforceのサービスアカウントなので、Workflowsの続きに戻ります
数秒のうちに、侵害された静的な裏口アカウントを、ゼロスタンディング特権の動的なアカウントへと変えていました
なお、会場ではスマホで撮影する人が多く、「このWorkflowsは公開する予定」とのアナウンスもありました
続いてOkta Privileged Access（OPA）の画面です
オンボードされた瞬間にパスワードはローテーションされているため、漏洩・悪用されたクレデンシャルはもう使えません
裏口は閉じられ、今このパスワードを知っているのはOPAだけ、人間は誰も知らない状態です
セキュリティチームはこれで一安心ですが、Salesforceエンジニアが業務でこのアカウントを使う必要がある場合はどうするのか？
そこで登場するのが「排他的チェックアウト」と「ゼロスタンディング特権」です
ちなみに、ゼロスタンディング特権（Zero Standing Privileges）というのは、特権を常時付与しておかず、必要なときに必要な時間だけ与える考え方のことです
OPAのSalesforceプロジェクトでは、配下で保護されているすべてのアカウントに対してチェックアウトが有効化されています
さらにセキュリティポリシーで、クレデンシャルを表示する前に満たすべきJIT（Just-In-Time）アクセス条件が設定されていました
ここで登壇者が「Salesforceエンジニア」に役割を切り替えてデモを進めます
従来であれば、静的なパスワードをチーム内で共有し、必要なときにコピーして使ってそのまま…というのがよくある運用でした
OPAでは、エンジニアの画面にパスワードは表示されておらず、アクセス条件を満たすためにリクエストが必要です
「セキュリティがビジネスの足を止めてはいけない」とし、アクセスをリクエストするとOIGを経由して承認者に直接届きます
エンジニアの画面に戻ると、クレデンシャルがチェックアウト可能になっていました
ここでは2つの重要なコントロールが効いています
排他的チェックアウト
同時にクレデンシャルを保持できるのは1人だけ
これにより、このアカウントに対する厳格な否認防止（誰が使ったかを言い逃れできない状態）が担保されます
時間制限
チェックアウトの残り時間は1時間
「クレデンシャルを所有しているのではなく、リースしているだけ」と表現していました
パスワードをコピーしてSalesforceにログインし、必要な作業を終えたらログアウトしてチェックイン
チェックインした瞬間、もしくはタイマーが切れた時点で、OPAがSalesforce側のパスワードを再度ローテーションします
つまり、30秒前にクリップボードにあったパスワードはもう使えません
そして、一連の操作はすべて監査証跡として残ります
これがJITとゼロスタンディング特権の実践だと締めくくり、デモパートが終了しました
最後にスライドに戻り、振り返りがありました
管理外のSaaSの脆弱性を、エンジニアリングの速度を落とすことなく完全に統制された資産へと変え、攻撃者に盗むものを何も残さない
これがこのセッションのメッセージでした
ISPM、ITP、Workflows、OPA、OIGと、Oktaの製品を横断してNHIのライフサイクルを一気に回す、見応えのあるデモセッションでした
個別の機能を知る機会やセッションはあるのですが、組み合わせて何ができるかを理解するにはとても良いセッションでした