静的な資格情報は依然としてAIが最も簡単にアクセスできる方法です

AIは過剰権限の資格情報を発明したわけではなく、それを使う最速の方法を見つけただけです。あなたの環境で動作するすべてのエージェント、スクリプト、統合は何かで認証しており、多くの環境ではそれがパスワード、APIキー、または一度発行されて二度と触られないトークンです。人はパスワードを忘れて最終的にロックアウトされますが、機械のIDは誰も見ていない限り与えられたものを使い続けます。

より多くのアイデンティティ、より多くの侵害

今年、2,317人のセキュリティおよびITリーダーに調査を行いました、そして結果で最も明確な数字はこれでした：AIが環境内のアイデンティティ数を大幅に増加させた組織は、過去12か月間で43％の侵害率を報告しました。AIがアイデンティティ数をあまり変えていない組織は11％を報告しました。これは4倍の差であり、AIが多いグループのセキュリティが全体的に弱かったからではありません。私たちのデータは、彼らがほとんどの基本を先行していることを示しています。

彼らが先を行っていなかったのは 非人間的なアイデンティティ ガバナンスです。76％の組織が非人間的なアイデンティティを完全に管理または監視していないと答え、19％だけがそうだと言いました。これがAIが扱っている人口です：ほとんどが発行された日以来誰も確認していない資格情報で認証している増え続ける機械のアイデンティティの集合体です。

静的認証情報

静的な認証情報は自動的に期限切れにならず、自動でローテーションされず、何回使われても気にしません。これが、自動化された何かの中にあるときに危険な理由です。盗まれたパスワードを使う人は最終的に気づかれますが、盗まれた認証情報を使うAIエージェントやスクリプトは、ワークフローが許す速度でずっと動き続け、誰かに見つかるまで止まりません。

NHI認証情報を保護する手順

1. ボールト

最初のステップは、スクリプト、設定ファイル、スプレッドシート、ソースコードから資格情報を取り出し、それらを保存するために構築されたシステムに移すことです。これは簡単そうに聞こえますが、ほとんどの場合そうではありません。ボールトは、戦略的およびレガシーアプリケーション全体で機能し、各アプリが資格情報にアクセスする方法に応じて異なるアクセスパターンをカバーし、集中型オンボーディングと一部のチームが常に手動で資格情報を追加する現実の両方をサポートする必要があります。実際には、ユーザー向けのプレゼンテーション層、ビジネスロジックと権限を強制するアプリケーションサーバー、実際に秘密情報を保存するデータベース層からなる多層アーキテクチャを意味し、地理的に分散したチーム間で負荷を分散するために複数のアプリケーションサーバーをスケールアウトするオプションがあります。ボールト化はまた、最も早く効果が現れるステップでもあり、誰でも見つけられる資格情報と実際に管理されている資格情報の違いを生み出します。

2. 暗号化

資格情報がボールトに入ったら、資格情報自体と同じくらい慎重に暗号化キーを管理しながら暗号化されたままでいる必要があります。これは単にAESをオンにして終わりというわけではありません。適切に構築されたボールトは、資格情報自体に対して認証付き暗号化（AES-GCM 256）を使用し、ユーザーおよびキーのハッシュ化には高い反復回数の強力なキー導出関数を使用し、公開鍵・秘密鍵交換には楕円曲線暗号を使用すべきです。すべての秘密コンテナは独自にランダム生成されたソルトを持ち、すべてのパスワード、ユーザー、およびロールは独自の鍵ペアを持つべきであり、アクセスは単一の共有鍵によって制御されるのではなく階層的に暗号化されます。Active Directoryと同期する環境では、サーバー自体が平文にアクセスしないエンドツーエンド暗号化モードが最も強力なオプションとして利用可能であるべきであり、集中管理が必要な組織向けにマスターキー・モードも併用されるべきです。マスターキー自体は構成ファイルではなくハードウェアにあり、HSMによって保護されるべきです。このように構築された暗号化ボールトにパスワードを平文から移行することは、組織が資格情報リスクを減らす最も一般的な方法であり、NHIセキュリティにまだ取り組んでいないチームにとって最も手の届きやすいステップです。

3. サイクリングと回転

資格情報を定期的にローテーションすることで、退職した従業員に関連するリスクを削減し、古いコードやスクリプトに残っている露出を整理し、誰も知らなかった依存関係を明らかにすることがよくあります。また、これは実行が最も難しいステップでもあります。特定の資格情報に依存するすべてのスクリプトや統合を知らない場合、ローテーションするとリスクを減らすどころか本番環境を壊す可能性があります。

ローテーションは、資格情報を保持しているボールトに密接に結びついた継続的な自動化プロセスとしてのみ機能し、誰かが手動で行うタスクではありません。つまり、カレンダーのリマインダーではなく、トリガーベースのリセットです：資格情報が閲覧されてから一定時間後、一定期間変更されていない後、または期限切れ後に資格情報をリセットします。また、このプロセスは自己保護しなければなりません。Active Directoryアカウント、WindowsまたはLinuxのローカルユーザー、サービスアカウントでスクリプトによるリセットが途中で失敗した場合、システムは資格情報を最後に正常だった値に自動的にロールバックし、失敗を記録する必要があり、サービスアカウントを壊れた半端な状態にしておくべきではありません。すべてのリセット、ロールバック、およびブロックは記録されるため、失敗したローテーションは3週間後に説明できない障害として表面化するのではなく、即座に確認できます。

実際に進展を遂げる組織のほとんどは、まずボールトと暗号化を確実に行い、その後、依存関係を十分に理解して安全に設定できるようになってから、自動化されたトリガーベースのローテーションに取り組みます。

Password Secureをご紹介します

Active Directoryに紐づくすべてのサービスアカウントおよびアプリケーションアカウントは、誰かが強制しているかどうかに関わらず、従業員と同じポリシーエンジンを通過します。Netwrix Password Secure は3つのステップすべてを直接カバーします。

ユーザー、管理者、およびサービスの資格情報のための単一の暗号化されたボールトを提供し、FIPS準拠の暗号化（AES-GCM 256、PBKDF2強化キー導出、NIST P-521楕円曲線キー交換）がすべての秘密を保護します。ロールベースのアクセスにより、資格情報を必要とする人やプロセスのみがそれを取得でき、すべてのチェックアウト、リセット、およびロールバックを記録する完全なログブックがあるため、誰がいつ特定の資格情報に触れたかを確認できます。さらに、構成可能なトリガーベースのパスワードリセットがローテーション部分を処理し、資格情報はスケジュールまたは定義された条件で自動的にリセットされ、ターゲットシステムが変更を拒否した場合はロールバック保護が行われます。

サービスアカウントのパスワードがスプレッドシートに無期限に保存され、誰も壊すリスクを負いたくないために回転されない状態と、暗号化され、アクセス制御され、ログが記録され、組織が実際に管理するスケジュールで回転される場所に保存される状態の差です。