Labelbox、1PasswordでKubernetesへの常設の特権をなくし攻撃対象領域を98%縮小

生成AI向けの「データファクトリー」としてAIの開発元や企業のAIチームに高品質なデータを提供するLabelboxは、Kubernetesへの常設の特権アクセスを、1Passwordによるジャストインタイムのアクセスに切り替えました。攻撃対象領域は98%縮小し、リスクの高いアクセスの申請は90%減っています。手動の承認の92%は2時間以内に完了しています。同社の顧客には、Fortune 500の企業や先進的なAIの研究機関が名を連ねています。

導入前：過剰なKubernetesの権限がリスクを広げていた

AIデータサービスの最先端を走る同社は、顧客にサービスを提供するうえでKubernetesのような動的な技術を多用しています。速さは最優先事項ですが、セキュリティーも同じく重要です。シニアDevSecOpsエンジニアのAaron Bacchi氏は、エンジニアがKubernetesのポッドに持つアクセス権限を見直し、使える時間と範囲を絞りたいと考えていました。調べてみると、エンジニアはめったに必要としないGoogleの特権ロールを持ち続けていました。このロールでは、シークレットの編集や閲覧を含め、ポッドに対するリスクの高い操作が可能でした。同氏は、エンジニアの作業を遅らせずに、過剰な常設のアクセスをなくす方法を探していました。

選定：用途ごとの細かなロールを申請制に

同氏はまずエンジニアに聞き取りを行い、ポッドを直接操作する際にアクセスをどう使っているかの用途をまとめました。そのうえで、特定の作業にちょうど必要な権限だけを持つ細かなカスタムのRBACロールをKubernetesで作り、それらのロールへのアクセスを1Passwordで管理する形にしました。同氏は、エンジニアが狭いロールをレゴブロックのように組み合わせて目的を達成できるようになったと説明しています。

リスクの高い権限を、エンジニアが実際に必要とする具体的な機能に分けたことで、強すぎるGoogleのロールによるリスクを、エンジニアの仕事を妨げずに減らせました。現在、Kubernetesへのアクセスは全て一時的で期限付きとなり、同社のアクセスポリシーのもとで完全に監視・制御されています。

数字で見た導入効果

攻撃対象領域を98%縮小

同氏は移行を円滑に進めるため、強い権限を持つGoogleのエンジニア用のロールを廃止する前に、細かなRBACロールを使う期間を設けました。特権のRBACロールは申請すれば使える形にし、当初は誰のアクセス権も取り上げていません。ロールを取り上げるのではなく申請制にしたことで、まだそのアクセスを必要とするエンジニアからの反発を避けつつ、アカウントが乗っ取られた際の被害の及ぶ範囲を大きく減らせました。攻撃対象領域は98%縮小し、リスクの高いアクセスの申請も90%減っています。

申請したのは利用資格のある50名中10名ほど

意外なことに、利用資格のある50名のうち、実際に申請したのは10名ほどでした。エンジニアは、リスクの高い権限を必要とする人と、必要としない大多数に自然と分かれたのです。同氏は、上司もKubernetesのセキュリティーが引き締まったことを喜んでいたと振り返ります。常設のアクセスが24時間開いたままになる状態がなくなり、不要なリスクが取り除かれました。

手動の承認の92%が2時間以内に完了

常設のアクセスのリスクがなくなったことで、同氏はアクセスポリシーをリスクに応じて段階分けする余裕を得ました。開発段階のリスクの低いリソースでは、全員が閲覧のみの権限を持ちます。環境の機密性が高まり、可能な操作の範囲が広がるほど、手続きの手間も段階的に増やしています。中程度のリスクの操作には、1Passwordから申請すると自動で承認されるポリシーを作りました。同氏によると、エンジニアは人の承認を待たずに1回あたり8時間のアクセスを得て、監視と制御のもとでステージング環境に必要な変更を加えられます。手動の承認についても、92%が2時間以内に完了しています。

本番環境のように最も機密性の高いリソースでは、変更のたびにアクセスを申請してマネージャーの承認を得る必要があり、1Passwordを通じた多要素認証も求められます。同氏は、本番環境の変更は少し手間が増えるが、その環境の重大さを考えれば当然だと述べています。こうして全員が必要な権限でリソースにアクセスできる一方で、全てが監視され、制御された状態になりました。

今後：新しいチームにもAccess Flowを広げる

新しい機能やサービスが生まれるたびにチームが作られるため、重要なシステムへのアクセスの適切なバランスを保つことが求められます。同氏は、新しいチームに対応するため、チームのメンバーが自らAccess Flowを作れるようにする計画です。1Passwordの新しいRBACロールを使い、Access Flowの作成や監査のための閲覧など、関係者ごとに適切な権限を与え、最上位の管理者ロールは自身のような上級の利用者に限ります。社内の透明性と教育を高め、可能な限り自動化を使ってリソースに効率よくアクセスする方法をエンジニアに伝える取り組みの一環です。

この導入事例からの学び

同社は権限を取り上げるのではなく、申請しなければ使えない形に変えることで、エンジニアの反発を避けながら常設の特権をなくしました。結果として、利用資格のある50名のうち申請したのは10名ほどでした。Kubernetesを運用する組織が確認すべきは2点です。1つは、広いロールを用途ごとの細かなロールに分けられるかどうかという点です。強いロールを1つ与えるだけの構成では、必要な人と不要な人を区別できません。もう1つは、リスクに応じて承認の手間を変えられるかどうかです。同社では、中程度のリスクは自動承認、本番環境はマネージャーの承認と多要素認証という形で、速さと統制を両立させています。

出典：1Password