キーポイント
- For highly dynamic cloud environments, VPNs and bastion hosts are inadequate as effective access management mechanisms
- A non-repudiable user identity established by an identity provider (as opposed to relying on network layer concepts such as IP addresses) is a core underpinning of access management in the cloud
- Short-lived ephemeral tokens or certificates eliminate the need for users to remember or store static credentials, which may be vulnerable to leaks and attacks
- 3rd party SaaS tool accesses to data, which cannot be controlled using VPNs, can be monitored just as effectively as those by internal users and tools
- User productivity is improved by providing a consistent access experience across all cloud resources -- SSH hosts, databases, S3 buckets, etc. -- even as administrators can exercise fine-grained control over them
アクセスマネジメントとは何か?
アクセスマネジメントは、ユーザまたはユーザのグループが、ホスト、サービス、データベースなどの特定のリソースにアクセスできるかどうかを識別するプロセスです。たとえば、開発者が SSH を使用してプロダクションアプリケーションサーバにログインできてもよいですか? その場合、どのくらいの時間ログインできますか? SRE がオフコール時間中にデータベースにアクセスしようとしている場合、アクセスを許可する必要がありますか? データエンジニアが別のチームに移動した場合、ETL パイプラインの S3 バケットに引き続きアクセスする必要がありますか?
今日のアクセスマネジメントはどのように行われているのか?
クラウド上にさまざまなインフラストラクチャとデータサービスが普及する前は、アクセスマネジメントは DevOps とセキュリティチームにとって解決は比較的単純な問題でした。VPN と踏み台サーバ (bastion hosts) は、ネットワークレベルですべての重要なリソースを遮断するための好ましいメカニズムでした (そして今でもそうです)。ユーザは、プライベートネットワーク上のリソースにアクセスする前に、最初に VPN サーバで認証するか、踏み台サーバにログオンします。
これは、リソースが静的で、その数が比較的少ない場合にうまく機能します。ただし、プライベートネットワークのさまざまな部分で動的に発生するリソースが増えるにつれて、VPN / 踏み台サーバソリューションでは耐えられなくなります。
具体的には、VPN と踏み台サーバがアクセスマネジメントの効果的なメカニズムとして不十分な3つの領域があります。
- ネットワーク層での操作: ひとたび、ユーザが VPN で認証し、プライベートネットワークへのアクセスが可能になると、実行されているすべてのサービスに有効にアクセスできるようになります。ユーザの ID に基づいて、各インフラストラクチャまたはデータサービスの粒度でアクセスを管理することができません。
- 資格情報は攻撃のベクトル: VPN も踏み台サーバのどちらも、ユーザが資格情報を記憶して保存する必要があります。特に多数のユーザが関与している場合、セキュリティポリシーとしての資格情報の期限設定とローテーションは困難であるため、資格情報は潜在的な攻撃のベクトルになります。
- サードパーティの SaaS ツールの管理ができない: Looker、Tableau、Periscope Data などの SaaS ツールは、データエンドポイントに直接アクセスする必要があります。したがって、これらのツールを使用してデータにアクセスする人は、他のクラウドインフラストラクチャと同じメカニズムと資格情報を使用して認証することができません。
クラウドのアクセスマネジメントのための新しいアーキテクチャ
この記事では、SSH ホスト、データベース、データウェアハウスから、メッセージパイプライン、クラウドストレージエンドポイントまで、クラウドリソースの簡素化されたアクセスマネジメントソリューションを探しているクラウドネイティブ企業のための新しいリファレンスアーキテクチャを定義します。
VPN と踏み台サーバでは克服できない次の特定の課題を解決します:
- きめ細かいサービスレベルでのアクセス認可の実施
- 共有資格情報と個人アカウントマネジメントの排除
- サードパーティの SaaS ツールによるアクセスの管理
機密データを使用する組織は、さらに次のビジネス上のメリットが得られます:
- すべてのサービスにわたるセッションの記録とアクティビティの監視を通じて、FedRamp や SOC2 などのコンプライアンス標準を満たすための監査が可能になる
- アクセサの ID に基づいて機密データを制限または除去するためのきめ細かい認可ポリシーによるプライバシーとデータガバナンス
このアーキテクチャは、次の3つのコア原則に基づいて構築されており、その実装により、DevOps チームとセキュリティチームは、シンプルで一貫したエクスペリエンスでユーザの生産性を向上させながら、すべての環境を完全に制御できます。
- ユーザがアクセスするリソースで拒絶されない ID を確立する
- 静的な資格情報とキーの代わりに、短命で一時的なトークンと証明書を使用する
- すべてのリソースタイプにわたるきめ細かいアクセスポリシーをに1か所に1元化
次の図は、リファレンスアーキテクチャとそのコンポーネントを示しています。
前の図の VPN / 踏み台サーバは Access Gateway に置き換えられました。Access Gateway は実際にはマイクロサービスのコレクションであり、個々のユーザを認証し、特定の属性に基づいて要求を認可し、最終的にプライベートネットワークのインフラストラクチャとデータサービスへのアクセスを許可します。
次からは、個々のコンポーネントを見て、前に概説したコア原則がどのように達成されるかを確認することにしましょう。
Access Controller
このアーキテクチャを支える重要なインサイトは、ユーザがアクセスを必要とする可能性のある各サービスにその責任を負わせるのではなく、単一のサービス (Access Controller) へのユーザ認証の委任です。この種のフェデレーションは、SaaS アプリケーションの世界では一般的です。単一のサービスが認証を担当することで、アプリケーション所有者のユーザプロビジョニングとプロビジョニング解除が簡素化され、アプリケーション開発を加速します。
Access Controller 自体は、通常、実際の認証シーケンスのために Auth0 や Okta のような ID プロバイダと統合されるため、さまざまなプロバイダやプロトコルにわたって有用な抽象化を提供します。最終的に、ID プロバイダは、署名されたSAML アサーション、JWT トークン、または一時的な証明書の形式で、ユーザ ID の否認防止を保証します。これにより、ユーザ ID のプロキシとして信頼できるサブネットに依存する必要がなくなります。また、ネットワーク上のすべてのサービスへのアクセスをユーザに許可する VPN とは異なり、サービスの粒度でアクセスポリシーを構成できます。
認証を ID プロバイダに委任することの追加の利点は、ユーザがゼロトラストの原則を使用して認証できることです。具体的には、ID プロバイダポリシーを作成して、以下を実施できます:
- 評判の悪い地域や IP アドレスからのアクセスを禁止する
- 既知の脆弱性を持つデバイス (パッチが適用されていない OS、古いブラウザなど) からのアクセスを禁止する
- SAML 交換が成功した直後に MFA をトリガする
認証シーケンスは次のように機能します:
- ユーザは最初に認証を ID プロバイダに委任する Access Controller で認証します。
- ID プロバイダへのログインが成功すると、Access Controller は短命で一時的な証明書を生成し、署名してユーザに返します。あるいは、証明書の代わりにトークンを生成することもあります。証明書またはトークンが有効である限り、Access Gateway によって管理される認可されたインフラストラクチャまたはデータサービスのいずれかに接続するために使用できます。有効期限が切れると、新しい証明書またはトークンが取得されなければなりません。
- ユーザは、ステップ (2) で取得した証明書を選択したツールに渡し、Access Gateway に接続します。ユーザがアクセスを要求しているサービスに応じて、Infrastructure Gateway または Data Gateway のいずれかが、サービスへのアクセスを許可する前に、まず Access Controller でユーザの証明書を検証します。したがって、Access Controller は、ユーザとユーザがアクセスするサービスの間の CA として機能するため、各ユーザに拒絶されない ID を提供します。
Policy Engine
Access Controller はユーザの認証を実施しますが、Policy Engine はユーザのリクエストに対してきめ細かい認可を実施します。人にわかりやすい YAML 構文で認可ルールを受け入れ (最後の例を確認)、ユーザのリクエストとレスポンスでそれらを評価します。
オープンソースの CNCF プロジェクトである Open Policy Agent (OPA) は Policy Engine の優れた例です。単独のマイクロサービスとして実行することも、他のマイクロサービスのプロセス空間でライブラリとして使用することもできます。OPA のポリシーは、Rego と呼ばれる言語で記述されています。または、ポリシーの仕様を簡素化するため Rego の上にシンプルな YAML インターフェースを構築するのも簡単です。
インフラストラクチャおよびデータサービス自体のセキュリティモデルとは別の独立した Policy Engine を持つことは、次の理由で有利です:
- セキュリティポリシーを、サービスと場所に依存しない方法で指定できる
- 例えば、すべての SSH サーバの特権コマンドを禁止する
- 例えば、すべてのサービス (インフラストラクチャとデータの両方) に対して MFA チェックを実施する
- ポリシーを1か所で管理し、バージョン管理できる
- ポリシーをコードとして GitHub リポジトリにチェックインできる
- すべての変更がコミットされる前に共同レビュープロセスを通す
- バージョン履歴の存在によりポリシーの変更を簡単に元に戻すことができる
Infrastructure Gateway と Data Gateway はどちらも、ユーザによるインフラストラクチャとデータアクティビティをそれぞれ評価するために Policy Engine に依存しています。
Infrastructure Gateway
Infrastructure Gateway は、SSH サーバや Kubernetes クラスタなどのインフラストラクチャサービスへのアクセスを管理および監視します。Policy Engine とインターフェイスして、きめ細かい認可ルールを決定し、ユーザセッション中のすべてのインフラストラクチャアクティビティにそれらを適用します。負荷分散の目的で、ゲートウェイはワーカノードのセットで構成するか、AWS でオートスケーリンググループとしてデプロイするか、Kubernetes クラスタでレプリカセットとして実行することができます。
Hashicorp Boundary は、Infrastructure Gateway の一例です。これは、VPN や踏み台サーバの使用を排除して直接のネットワークアクセスを必要とせずに、きめ細かい認可でインフラストラクチャサービス (SSH サーバ、Kubernetes クラスタ) に開発者、DevOps、SRE が安全にアクセスできるようにするオープンソースプロジェクトです。
Infrastructure Gateway は、SSH サーバと Kubernetes クライアントで使用されるさまざまな接続プロトコルを理解し、次の主要な機能を提供します:
セッション記録
これは、セッション中にユーザが実行したすべてのコマンドのコピーを作成することが含まれます。キャプチャされたコマンドには、通常、ユーザの ID、属するさまざまな ID プロバイダグループ、日時、コマンドの実行期間、レスポンスの特性 (成功したか、エラーになったか、データの読み取りか書き込みか) などの追加情報が注釈として付けられます。
アクティビティの監視
監視は、セッション記録の概念を次のレベルに引き上げます。Infrastructure Gateway は、すべてのコマンドとレスポンスをキャプチャすることに加えて、ユーザのアクティビティにセキュリティポリシーを適用します。違反した場合、アラートをトリガするか、問題のコマンドとそのレスポンスをブロックするか、ユーザのセッションを完全に終了するかを選択できます。
Data Gateway
Data Gateway は、MySQL、PostgreSQL、MongoDB などのホストされたデータベース、AWS RDS などの DBaaS エンドポイント、Snowflake や Bigquery などのデータウェアハウス、AWS S3 などのクラウドストレージ、Kafka や Kinesis などのメッセージパイプラインへのアクセスの管理と監視をします。Policy Engine とインターフェイスして、きめ細かい認可ルールを決定し、ユーザセッション中のすべてのデータアクティビティにそれらを適用します。
Infrastructure Gateway 同様 Data Gateway は、ワーカノードのセットで構成することも、AWS でオートスケーリンググループとしてデプロイすることも、Kubernetes クラスタでレプリカセットとして実行することもできます。
インフラストラクチャサービスと比較してデータサービスの種類が多いため、Data Gateway は通常、多数の接続プロトコルと文法をサポートします。
このような Data Gateway の例としては、軽量のインターセプトサービスである Cyral があります。AWS RDS、Snowflake、Bigquery、AWS S3、Apache Kafka などの最新のデータエンドポイントへのアクセスを監視および管理するためのサイドカーとしてデプロイされます。機能は次のとおりです:
セッション記録
これは、インフラストラクチャアクティビティの記録に似ています、セッション中にユーザが実行したすべてのコマンドのコピーを作成し、豊富な監査情報で注釈を付けます。
アクティビティの監視
繰り返しになりますが、これはインフラストラクチャアクティビティの監視に似ています。たとえば、以下のポリシーは、データアナリストが顧客の機密性の高い PII の読み取りをブロックします。
プライバシーの実施
インフラストラクチャサービスとは異なり、データサービスは、データベース、データウェアハウス、クラウドストレージ、メッセージパイプラインに存在することが多い顧客、パートナ、競合他社に関連する機密データへの読み取りおよび書き込みアクセスをユーザに許可します。プライバシー上の理由から、Data Gateway でかなり一般的な要件は、電子メール、名前、社会保障番号、クレジットカード番号、住所などの PII を除去 (トークン化またはマスキングとも呼ばれる) する機能です。
では、このアーキテクチャがどのようにアクセスマネジメントを簡素化するのでしょうか?
いくつかの一般的なアクセスマネジメントシナリオを見て、VPN や踏み台サーバを使用する場合と比較して Access Gateway アーキテクチャがどのようにきめ細かい制御を提供するかを理解しましょう。
特権アクティビティの監視 (PAM)
これは、すべてのインフラストラクチャとデータサービスにわたる特権アクティビティを1か所で監視するための簡単なポリシーです:
- Admins と SRE グループに属する個人のみが SSH サーバ、Kubernetes クラスタおよびデータベースで特権コマンドを実行できます。
- 特権コマンドを実行することは問題ありませんが、例外の形でいくつかの制限があります。具体的には、次のコマンドは許可されません:
- SSH サーバで “sudo” および “yum” コマンドは実行できません。
- いかなる Kubernetes クラスタでも “kubectl delete” および “kubectl taint” コマンドは実行できません。
- いかなるデータベースでも “drop table” および “create user” コマンドは実行できません。
ゼロスタンディング特権 (ZSP) の実施
次のポリシーは、ゼロスタンディング特権を適用する例を示しています。これは、デフォルトではインフラストラクチャやデータサービスに誰一人アクセスできないパラダイムです。アクセスは、1つ以上の適格基準を満たした場合にのみ取得できます:
- サポートグループに属する人のみがアクセスを許可される
- アクセスする人はオンコールでなければならない。オンコールステータスは、PagerDuty などのインシデント対応サービスでスケジュールを確認することで判断できる。
- 認証が成功すると、多要素認証 (MFA) チェックがトリガされる
- インフラストラクチャやデータサービスへの接続に TLS を使用しなければならない
- 最後に、データサービスにアクセスしている場合、全テーブルスキャン (たとえば、データセット全体を読み取ることになる WHERE または LIMIT 句がない SQL リクエストなど) は許可されない。
プライバシーとデータガバナンス
最後のポリシーは、データ除去 (data scrubbing) を含むデータガバナンスの例を示しています:
- マーケティングが PII (社会保障番号 (SSN)、クレジットカード番号 (CCN)、年齢) にアクセスしている場合は、データを除去してから返します
- Looker や Tableau サービスを使用して PII に誰かがアクセスしている場合も、データを除去します
- 除去ルールは、PII の特定のタイプによる定義です
- SSN の場合は、先頭5桁の数字を除去します
- CCN の場合は、最後の4桁の数字を除去します
- 年齢の場合は、最後の桁を除去します。つまり、年齢層を知ることはできますが、実年齢はわかりません
まとめ
はげしく動的なクラウド環境では、VPN と踏み台サーバはアジャイルクラウド環境での効果的なアクセスマネジメントメカニズムとしては不十分であることがわかりました。拒絶されないユーザ ID、短期間の証明書またはトークン、および一元化されたきめ細かい認可エンジンに重点を置いた新しいアクセスマネジメントアーキテクチャは、VPN と踏み台サーバが解決できない課題を効果的に解決します。このアーキテクチャはさらに、重要なインフラストラクチャとデータサービスにアクセスするユーザに包括的なセキュリティを提供するだけでなく、監査、コンプライアンス、プライバシー、およびガバナンスの目標を組織が達成するのに役立ちます。
また、Hashicorp Boundary や OPA などの有名な開発者向けオープンソースソリューションを、最新のデータサービス用の高速でステートレスなサイドカーである Cyral と組み合わせて使用するアーキテクチャのリファレンス実装についても説明しました。これらを組み合わせることで、クラウド上できめ細かく使いやすいアクセスマネジメントソリューションを提供できます。
著者について
Manav Mital氏 は、データクラウドの可視化、アクセス制御、保護を提供する最初のクラウドネイティブセキュリティサービスである Cyral の共同創設者兼CEOです。2018年に設立された Cyral は、クラウドネイティブのスタートアップから Fortune 500 の企業まで、あらゆる種類の組織と協力して、データを管理および分析するための DevOps カルチャーとクラウドテクノロジーを採用しています。Manav は、UCLA でコンピューターサイエンスの修士号を取得し、Kanpur のインド工科大学でコンピューターサイエンスの理学士号を取得しています。