fbpx

CL LAB

HOME > AquaSecurity > CL LAB > 最新のクラウドネイティブセキュリティにおけるロールベースアクセス制御(RBAC) #AquaSecurity #コンテナ #セキュリティ #Kubernetes

最新のクラウドネイティブセキュリティにおけるロールベースアクセス制御(RBAC) #AquaSecurity #コンテナ #セキュリティ #Kubernetes

 ★ 3

本ブログは「Aqua Security」社の技術ブログで2020年6月18日に公開された「 Role-Based Access Control in Modern Cloud Native Security 」の日本語翻訳です。

最新のクラウドネイティブセキュリティにおけるロールベースアクセス制御(RBAC)


大規模な環境では、異なるクラウドネイティブプロジェクトやアプリケーションに取り組む複数のチームで構成されていることがほとんどです。このようなチームは、それぞれコンテナイメージや機能などを独自のアセットで作業して別々の CI パイプラインを使用しますが、最終的には同じクラウドインフラストラクチャ上で実行されることになるでしょう。このような権限と役割が複雑な環境におけるセキュリティ管理は、より多くのチームやステークホルダーが関与する事になると、すぐに厄介な事態に陥る可能性があります。管理を煩雑にすることなく、最小特権アクセスを確実に維持するにはどうすればよいのでしょうか。私たちはそのために、完全な RBAC モデルを再設計しました。

必要な場所へのアクセスを維持し、それ以外のアクセスを制限する

その性質上、大規模なクラウドネイティブ環境には開発者・クラウド運用担当者・SRE・セキュリティ運用担当者・脆弱性管理担当者・コンプライアンス担当者など、さまざまな役割を持つチームメンバーが複数のチームへ所属することになります。それぞれの役割には異なる権限が必要ですが、同時にチームは特定のプロジェクトやセキュリティレベルに基づいたアクセス権や、その可視性が必要です。これは CI パイプラインや個々のイメージから Kubernetes 内のクラスタやネームスペースに至るまですべてに当てはまります。

例えば、開発者は自分のコードの脆弱性を修正する必要があるため、脆弱性に関する情報の通知やアクセスができるようにする必要があります。しかし、開発者が一方的に脆弱性のリスクを許容すべきではありません。これはセキュリティの専門家に任せるべきであり、セキュリティの専門家は自分の領域と責任範囲内でのみ脆弱性を認識すべきです。しかし、企業のセキュリティチームのようにグローバルポリシーを設定したり、セキュリティイベントデータを集計したりする機能を必要とするチームもあります。

しかしながら、各チームに完全に別々のセキュリティシステムを導入するのは非現実的で、非常に非効率的です。職務分離(SoD)はあらゆるセキュリティ戦略において必要不可欠であり、多くのコンプライアンス規制においても要求されています。これを実現するためには階層とロールベースの権限を有効にし、定義されたスコープ(「アプリケーション」と定義されるもののあらゆる側面)に適用する必要があります。

アクセスは制限されるが、生産性や柔軟性は制限されない

Aqua の新しいマルチテナント・ロールベースアクセス制御(RBAC)機能により、さまざまなプロジェクトやアプリケーションを分離して、割り当てによるアクセスを制限できます。このアプローチは生産性を維持し、あらゆるタイプのデプロイメント・セキュリティ・組織構造をサポートする柔軟性にも優れています。

SoD はユーザ・ロール・権限セット・アプリケーションスコープを中心に構成されています。

これらのコンポーネントを組み合わせることで、適応性の高いモデルを提供します。これにより管理者はアプリケーションの単位あらゆる側面を本質的に包含するスコープを設定できます。そしてきめ細かなパーミッション(アセットやケイパビリティへの読み取り専用や変更権限アクセスなど)を取得し、それらをロールに割り当てることができます。最後に特定のユーザには1つ以上のロールが与えられます。これは通常 LDAP や Active Directory のグループからマッピングされるので、最初からユーザのセキュリティグループやロールを定義する必要はありません。

実際のマルチアプリケーションに対する RBAC 設定

ある組織に2つのチームがあるとします。1つは CRM アプリケーションを実行しているチーム、もう1つはeコマースアプリケーションを実行しているチームで、それぞれが別々のレジストリを使用しているとします。eコマースアプリケーションは別のクラスタで実行されており、CRM アプリケーションは別のクラスタ内の Namespace で実行されています。各チームには特定の権限を必要とする内部のステークホルダーと、完全または部分的な権限を持つグローバルな OOTB スコープを持つ外部のステークホルダーがおり、両方の環境に対する可視性を必要とする管理者がいます。

典型的な関係者の役割には、開発者、アプリケーション管理者、クラウド運用管理者、SecOps管理者(OOTB ユーザ)などがあります。開発者は、アプリケーションに関連するワークロード・リスク・ポリシーを閲覧できますが、それを編集することや監査イベントの閲覧はできません。アプリケーション管理者は、アプリケーションに関連するワークロード・リスク・ポリシーを閲覧し、編集や監査イベントの閲覧ができます。クラウド運用担当者は、K8s のコンプライアンス情報を閲覧できますが、脆弱性やセキュリティポリシーを閲覧できません。SecOps 管理者(OOTB ユーザ)は、システム内のすべてのリソースを閲覧する必要があります。

Aqua を使用して、これらの異なるロールのアクセスとパーミッションを定義するのは簡単です。まずパーミッションセットを定義し、各アプリケーションのアプリケーションスコープを設定して、パーミッションセットとアプリケーションスコープを組み合わせたロールを定義します。これらのステップが完了すると、ユーザはロールに割り当てられます。これで Aqua コンソールは割り当てられたロールのみに基づいて、これらのユーザに情報を表示するようになります。多くのデフォルトロールを提供していますが、カスタマイズしたり、ゼロから作成したりすることも可能です。

まとめ

現代の企業環境は複雑で、異なるプロジェクトやアプリケーションに取り組む複数のチームで構成されています。アプリケーションチームを健全で効果的な状態に保ち、CISO が夜も眠れ、違反や攻撃の原因となる過剰な権限を回避するためには、これらのチームが関連するアプリケーション・役割・レベルにのみ制限されたアクセスを持つ必要があります。つまり、各ユーザは自分が作業しているリソース(成果物・ワークロード・インフラストラクチャ)・対処すべき関連セキュリティリスク(脆弱性やランタイムイベント)のみを可視化し、自分の役割に基づいたセキュリティポリシーへの読み取り・書き込みアクセスを許可する必要があるということです。

過去数年にわたり、Global 1000の世界最大級のクラウドネイティブデプロイメントの多くのセキュリティを確保してきたことで、Aqua ではこれらの複雑さを理解し、大規模・マルチアプリケーション・マルチチーム環境における安全な RBAC のための包括的なモデルを開発することができました。

New call-to-action

New call-to-action

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post