3 強力なパスワードのためにはどうすればよいか？
特権パスワード管理の各論に深く切り込む前に、ここで、ほぼあらゆるタイプのパスワードに共通のパスワード管理のベストプラクティスについて述べます。
- パスワードを12文字以上の長さにする
- パスワードは独自の複雑さを持つ意味のないものにし、繰り返さずに様々な文字（大文字と小文字）を組み合わせて混ぜ、数字や記号も入れて、どのような言語でも辞書に載っている言葉は入れず、推測できるような内容（従業員のIDや日付など）や、「qwerty」あるいは「zxcvb」といったキーボードの並び配列を含まないようにする
- パスワードの使い回しを避ける。従業員に対し、個人のアカウントと仕事用のアカウントで同じパスワードを使うのを禁じる
- パスワードを共有する必要が生じたときは、他の人がそれを使った作業を終えるたびに変更するようにする
- パスワードの頻繁な変更－－パスワード変更やパスワード定期変更と呼ばれる手順である
パスワード変更について言えば、現行のNISTガイダンスでは、パスワードに侵入されたという事実または疑いがあるような特殊な場合を除き、個人のパスワード変更を強制しないようにと勧告しています。しかし、パスワード変更はやはり、特権資格情報を保護する上で欠かせないベストプラクティスです。変更の頻度は、パスワードの古さや使用状況、セキュリティの重要性などに合わせて変える必要があります。たとえば、最重要アカウントに関しては、スーパーユーザアカウントや他の高度な特権パスワードを、使い終わるたび－一時パスワードまたは（One Time Password, OTP）と呼ばれる－など、より短い期間で変更することを考えるべきです。
人間が管理するパスワードの落とし穴
上記で挙げたパスワードのベストプラクティスはかなり単純に見えますが、こうした原則を実行に移すのが難しいのはなぜでしょう？
現在、従業員が様々なアカウントやシステム、アプリケーションにアクセスするために覚えておかなければならないパスワードの数は10個以上、ときには100個以上に及びます。組織の特権資格情報に関して言えば、管理すべきパスワードは1万から100万を超えることもざらにあるのです。
これほど多くのパスワードを手作業で記憶しておかねばならないという負担のため、資格情報の窃取や悪用を増やし、停止時間の原因を作るといった形で、従業員が失敗を犯すことになるのは当然でしょう。従業員がパスワードを忘れることもたびたびあり、システムから締め出される可能性も高くなります。それを防ぐために、彼らは複数のアカウントに対して同じパスワードを使い、簡単に推測できるパスワードを選択し、紙やMS Wordまたはスプレッドシートなどの電子文書に、メールアドレスやユーザ名と一緒にパスワードを書き留めておくこともあります。その結果、ハッカーが侵入したアカウントからのパスワードを、メールアドレスやユーザ名と併せて、同じパスワードを使っていると思われる他のサービスに関連づけることができるという危険が生まれます。だから、たとえばあるサーバやアプリケーション、スイッチ、ソーシャルメディアのアカウントに同じ特権資格情報を使うことで、一つのアカウントへの侵入が他のアカウントへの侵入につながってしまうのです。
現代の企業では、侵入の危険を減らすための自動パスワード管理が必須の手段となっていますが、多くの組織はいまだに手作業または人手によるパスワード管理方法にある程度は頼っています。その結果、実際には特権パスワードの変更と監視がうまく行われず、組織は特権資格情報の悪用という危険にさらされることになるのです。
特権パスワード管理の課題
では、企業の特権資格情報により特化した課題をいくつか検証してみましょう。
全ての特権アカウントを見ることができず、気づくことができない
特権アカウントは、長期にわたって放置されたまま、ほとんどのIT環境に拡散されていることが多いものです。それは人的IDと非人的IDの両方に関連付けられたアカウントも同じで、企業全体の資格情報は、とりわけ手作業の処理やツールに頼っている企業にとっては、一つの大きな課題となります。それぞれのチームが個別に自身の一連の資格情報を管理している－そもそも管理しているならば－ため、全てのパスワードの履歴管理、ましてやそれにアクセスした人や使った人の履歴管理は非常に難しいのです。管理者は100以上のシステムにアクセスすることもあり、おそらく資格情報を保守する際には手間を省くような配列のしかたをしているでしょう。これに加えて、下記で詳しく述べますが、資格情報の種類によっては見つけることが実質的に不可能であり、ましてサードパーティのツールを使わずに管理することなどできません。
特権資格情報の監督と監視ができない
企業全体に散らばっているすべての特権資格情報をIT担当者が首尾よく発見できたとしても、それだけで特権セッションの間（すなわち、あるアカウントやサービスや処理に対し、昇格した特権が許諾されている期間）に、具体的に何が実行されたかを知ることはできません。スーパーユーザへの特権アクセスによって、ユーザに白紙委任状を渡すようなことになってはならないのです。それに、PCIやHIPAAなどの規格では、組織は単にデータを安全に保護するだけでなく、そのための手段の効果を証明できることが求められています。ですから、コンプライアンスとセキュリティ両方の理由で、IT担当者は特権セッションの間に行われた動作を見られるようにする必要があるのです。
理想を言えば、IT担当者は、資格情報が不正に使われた場合に備えて、セッションの制御を掌握できる必要があります。しかし、一つの企業全体で数百または数千という特権セッションが同時に行われている状況で、IT担当者は、悪意のものであれ過失によるものであれ不正な行為を、どうすれば迅速に検出して止めることができるでしょう。アプリケーションやサービス（Active Directoryのような）によっては、ユーザの動作を記録でき、Event Logデータ内のログオンイベントを使っているWindowsサーバは異常なふるまいを発見することができますが、特権アカウントの使用全般に渡ってこれを行うには、サードパーティによる企業規模のソリューションが必要なのはほぼ間違いありません。
便宜のために特権アカウントを共有する
ITチームは一般に、作業や任務をシームレスに共有できるように、root特権やWindowsのAdministratorや他の多くの特権アカウントを共有しています。しかし、複数の人間が一つのアカウントを共有すると、個別に実行された動作を追跡することが不可能になる可能性があり、監査や信頼性が複雑になります。
ハードコード化された/組み込まれた資格情報
特権資格情報は、アプリ間（A2A）とアプリケーション・データ間（A2D）のやり取りとアクセスのため、またロボット処理自動化（RPA）のような新生の領域のための認証を円滑に行うのに必要です。アプリケーション、システム、IoTデバイスは通常、簡単に推測できる組み込まれたデフォルトの資格情報と共に出荷されて展開されることが多いため、管理下に置かれるまでは非常な危険にさらされています。DevOpsツール、スクリプト、試験用サーバ、本番用ビルド全体に拡散した秘密情報もまた、よくある盲点の一つです。こうしたすべての種類の非人的特権資格情報/秘密情報は、平文で－おそらくスクリプトやコードやファイルの中に－保管されていることが多いものです。残念ながら、アプリケーションやスクリプトの中に保管されているパスワードを手作業で検出したり一元管理したりする方法はありません。組み込まれたパスワードと秘密情報を保護するには、パスワードをコードと切り離し、使われていないときは平文のまま常に人目にさらしておくのではなく、一元化されたパスワード保管庫に安全に保管する必要があります。
SSH鍵
ITチームは通常、サーバへの安全なアクセスを自動化し、ログインの資格情報を手作業で入力しなくてもすむように、SSH鍵を使っています。SSH鍵の拡散は多くの組織にとって非常に大きなリスクで、それは百万ものSSH鍵を持てば、その多くは休止状態で放置されることになるのに、ハッカーが基幹サーバに入りこむための致命的なバックドアとなってしまうからです。SSH鍵は特にUnixとLinuxでは標準的で普及が進んでいますが、Windowsでも全体的に使われています。管理者はSSH鍵を使ってオペレーティングシステム、ネットワーク、ファイル転送、データトンネリング、その他の管理を行います。SSH鍵は必ずしも一人のユーザにひもづけられているわけではなく、複数の人間がこの秘密鍵と、公開鍵を持つサーバへのパスフレーズを共有することができます。他の種類の特権資格情報と同様に、組織が手作業での処理に依存している場合、多くのSSH鍵でパスフレーズを再利用し、同じ公開のSSH鍵を再利用する傾向が強くなります。つまり、鍵が一つでも侵入を受ければ、複数のサーバに入りこむための経路ができてしまう可能性があるのです。
特権資格情報とクラウド
可視性と監査能力という課題は一般に、クラウドや仮想環境で悪化しやすいものです。クラウドと仮想環境の管理者のコンソール（AWS、Office 365などを持つ）は、広範囲にわたるスーパーユーザの権限を与えるため、ユーザは広い範囲で迅速にサーバをプロビジョニングし、構成し、削除することができます。こうしたコンソールの中では、ユーザはほんの数回のクリックで、数千もの仮想マシン（それぞれに一連の固有の特権と特権アカウントがついている）の操作性を高め、管理することができます。すると今度は、そうして新しく作成された特権アカウントと資格情報の全てをどのように登録し管理するかということについて難問が生じます。その最たるものとして、クラウドのプラットフォームの多くがユーザ動作を監視する固有の機能を持たないということが挙げられます。しかも、ある程度は自社のパスワード管理に自動化を取り入れている（自社製であってもサードパーティのソリューションであっても）組織にとっても、クラウドを想定したアーキテクチャを持っていなければ、一つのパスワード管理ソリューションで適切にクラウドの資格情報を管理できるという保証はどこにもないのです。
サードパーティベンダーのアカウント/リモートアクセスソリューション
最後に、組織にとってもう一つの難題は、さまざまな活動を行い、ネットワークでつながれたシステムにアクセスする必要があるコンサルタントや他のベンダーといった第三者のユーザに対し、特権アクセスと資格情報の管理のベストプラクティスをどのように拡張するかということです。リモートアクセスを介して、または第三者に対して与えられた承認が適切に使われていることをどう確認すればいいでしょう？ 第三者機関が資格情報を共有していないこと、または従業員が会社を辞めた場合に承認用の資格情報を終了しないなど、パスワードの扱いがお粗末になっていないことを、どのように保証すればいいでしょう？