Unity の資格情報管理について

Unity のセキュアソフトウェア開発ライフサイクル（SSDLC）の一環として、弊社の資格情報の管理戦略を共有したく思います。コードでトークン、キー、そして資格情報（別名シークレット）を管理するのは、かなり面倒な作業だと言えます。これらの点についての詳細を記すことで、私たちが辿ってきた道を捉えていただき、それがご参考となれば幸いです。

数年前、Unity セキュリティチームは、インフラチームの Unity パートナーと共同で、資格情報管理の問題に正面から取り組もうということで、パートナーそれぞれの狙いを定めることにしました。Unity のような多様で大規模な環境においては、プロジェクトは数多のプログラミング言語のうち、その 1 つで記述されて、複数の異なった環境で開発され、そして継続的に行われる統合化での大量のツールチェーンが配備されることになります。こうなってしまうと資格情報の管理はさらに大変で手間がかかる作業となってしまいます。本記事では、同じ問題を持つ皆さまの指標になればと、弊社のソリューションをオープンソース化するだけでなく、私たちが辿ってきた道程についても記述しております。

そう、資格情報は管理する必要があります。でも、それって何ですか？ シークレットとも呼ばれる資格情報とは、リソースや他のサービスにおいての特権操作を実行する際にあなたが使用するサービス側から要求される部分、すべての情報です。これは、API のトークン、一部のサービスにログインするためのパスワード、外部サーバーに接続するための SSH 秘密鍵、ストレージバケットに書き込むための一連の資格情報、あるいはバイナリに署名するための RSA 鍵などが該当します。どんなタイプの資格情報であっても、対象の情報は慎重に守られて、使用対象となる処理に関わっている一部の当事者だけが知っている状態にしなければなりません。理想的には、そのサービスに取り組んでいる開発者ですら、知らない方が良いでしょう。最低でも、対象情報を必要なときだけ利用すべきなのです。

強固な資格情報管理戦略における 2 つの目標とは、資格情報が悪意のある当事者の手に渡らないようにすることであり、そして開発者にとって過度に複雑化するような作り方とならないように資格情報を取り扱うことです。しかし、それは口で言うほど簡単なことではありません。

資格情報管理戦略を確立するとなると、チームは以下のような一般的問題を事前に予測しておかなければなりません。

• コード中の資格情報：資格情報を扱い、保存する場合に一番やりやすく、また残念なことに最もありがちなアプローチは、必要となる箇所に使われる変数をコードファイルへ直接書き込んでしまうことです。良い資格情報管理への糸口としては、コードへ資格情報を書き込むことについては別の手段で行えるように都合をつける必要があります。
• 資格情報のローテーション：資格情報の有効期限切れ、誤って非アクティブ化にしてしまった場合など、様々な事情に対してローテーション化しておく必要があります。良い資格情報管理方法としては、資格情報は手軽にローテーション化できるようにすべきでしょう。
• 多様な開発環境：Unity では多種多様なプログラミング言語を取り扱っていることから、資格情報管理は特定のプログラミング言語や開発環境に紐づけてしまうことは避けるべきです。大きく可能な限りの数で開発者やプロジェクトをサポートしてあげる必要があります。
• アクセス制御：人がチームに参加したり離れたり、新しいプロジェクトが始まったりと、資格情報は絶え間なく追加されていきます。適切なソリューションとしては、このような開発環境の流動性にも対応する一方で、その資格情報へのアクセスについては厳密に制御しなければなりません。
• ヒューマンエラー：ソリューションというものは、ユーザー側と管理者側の両方でヒューマンエラーを最小限に抑えられるように設計しましょう。たとえば、コンフィグレーション内のシンタックスは表現に富み、明示的でなければならない、そして破壊的な操作で意図せぬ変更が行われる可能性を最小限に抑えるために最低限の実行確認を導入する必要があります。
• マトリョーシカ人形（ロシアの入れ子人形）の問題：おそらくこれが最も致命的なポイントとなる部分と言えます。資格情報を安全に保存するには、しっかりと鍵をかけておくべきなのです。そして、任意のサービスが資格情報を要求した場合にだけ、アンロックするための鍵にアクセスすべきでしょう。ここで問題です。この鍵が安全であると、どうすれば確信できるのでしょうか？そうですね、鍵を資格情報として扱い、セキュリティ上、安全にロックしましょう。では、どうやってそのキーを守るのですか？察しの良い方なら、何が起こっているかをおわかりですよね。こうやって、資格情報を守る資格情報という、マトリョーシカ人形のような入れ子構造が繰り返されることになってしまうのです。

慎重な協議の末、弊社では米 HashiCorp 社の Vault を使うことを選択いたしました。この資格情報管理ソリューションのおかげで、私たちが抱えていた問題のほとんどに対処することができたのです。さらにオープンソースのソリューションとして利用できるバージョンも存在しています。

Vault では、安全に資格情報を保存し、それらに対して厳密な管理のもとにアクセスを行えるようにした上で、ユーザーが資格情報を取得出来るようにもできるソリューションを提供してくれます。残念ながら、開発者は資格情報を取得し使用するために、Vault ライブラリを自身のプロジェクトに統合する際、未だ手動で行う必要がありました。致命的なのは Vault はマトリョーシカ問題にまだ対処していなかったという点です。もちろん、資格情報を格納するための安全でセキュアな場所が得られましたが、それらの情報へのアクセスには、さらにトークンを必要とします。Vault の使用でより良い立場へと進むことはできるのですが、それでも問題をもう一段上のレベルに押し上げてしまうことも否めません。

依然として残る問題に対処するために、弊社ではいくつか既存のツールを検討しましたが、特にユーザーの使い勝手の良さなども考慮に入れると、要件すべてと合致するものはありませんでした。そのような事情から、私たちは Vault Secret Fetcher（VSF）を作成いたしました。 VSF は、GKE/Kubernetes または Google Compute Engine を通す形で認証を手配することで、コーディングにはびこる「マトリョーシカ人形問題」を一段階別に切り上げるように動作してくれます。その際、初期認証はオーケストレーションか、基盤となるインフラプラットフォームへ任せてしまえます。Vault では多様な認証メカニズムでの配列をサポートされているため、この動作は他のどんなインフラストラクチャでもサポートできるように調整が簡単になっています。

開発者のすることと言えば、Vault へシークレットを記述することだけです。

vault write secret/<YOUR PATH> token="..."

そしてサービスの環境でパスのプレースホルダーを割り当てましょう。

TOKEN = ‘VAULTSECRET::{"path":"secret/sre/dev/TEST", "key":"token"}'

資格情報のフェッチのフローは、以下のようになります。

1. 最初に VSF を呼び出し、サービスが起動します。
2. VSF は、認証プロバイダー（例：Kubernetes）を介して認証を行います。
3. VSF は、設定されたパスをコールし、Vault から資格情報を取得し、自身の環境下での資格情報変数を満たすようにします。
4. VSF は、サービスのエントリーポイントを呼び出し、自身のメモリ空間をサービスに置き換えます。これにより、サービスが資格情報へアクセスできるようになります。

このプロセスの詳細については、このプロジェクトの README をご覧ください。

オープンソースプロジェクトとして Vault Secret Fetcher をリリースいたします。ぜひともお試しいただき、プロジェクトにお役立ちいただけるような部分などご一考いただければと思います。弊社は皆様のご協力を心から感謝しております。

今後は、Vault Secret Fetcher をより一層使いやすいものにし、数多くのプラットフォームやユースケースをよりサポートできるようにする方法を模索していきます。