特権IDアクセス管理をクラウド環境に適用する

Security
Author: Dan Blum, CISSP
Date Published: 18 5月 2020
English

ITにおける特権は石油のようなものです。石油がなければ機械は動きませんが、大量にありすぎても混乱を招いてしまいます。業界では、長年にわたり特権の取り扱いについて取り組んできました が、ハイブリッド・マルチクラウド・コンピューティング環境の普及に伴い、特権付きアクセス管理(PAM)を改善しなければなりません。PAMの改善における重要な要件は以下のとおりです。

  • PAMとIDガバナンス・アドミニストレーション(IGA)との統合強化
  • ジャストインタイム(JIT)アクセスのサポート
  • DevOpsパイプラインおよびサービスアカウントとの統合

過度の特権付与とデータ侵害

多くの組織では、過度に特権が付与されたIT管理者やパワーユーザーに起因する高いリスクにさらされています。データ侵害レポートでは、特権の悪用が最も一般的なインサイダー脅威ベクトルに数えられると警告しています。

深く掘り下げて調査してみたところ、外部からのサイバー攻撃の成功例の多くは、特権IDアクセス管理に失敗していたことが判明しました。インシデントの多くは、特定のユーザーアカウントを狙ったスピアフィッシングから始まりますが、通常、ハッカーが本丸に辿り着くためには、幾層もの防衛層を突破しなければなりません。こうした水平方向への移動の傾向として、特権ユーザーアカウントやサービスアカウントを悪用する必要があります。

従来のPAMソリューション

規制コンプライアンスでは、最小限の特権付与や職務分離などのコントロールを義務付けています。 したがって、2000年代初頭からPAM製品が組織をサポートしてきたのは、図1に示すユースケースやコントロールでした。

Applying-Privilidge

既知の問題

理論上、PAMシステムには優れた機能はあるかもしれませんが、使えるようにするのは極めて難しいという問題があります。1重要な課題は、PAMが作業の妨げになるとき、開発者とIT管理者がPAMに抵抗する傾向があることです。Lieberman Softwareの前CEOであるPhillip Lieberman氏は、数年前にこう述べました。「誰も当社の[PAM]製品をインストールしません。なぜなら、インストールしたくないからです。誰かに強いられない限りインストールしないのです」と。2

PAMは、プロジェクトとしてではなく、プログラムとして管理する必要があります。PAM要件が脅威と規制を取り入れながら拡張するにつれ、担当者はその理由を説明したり、事前により多くの賛同を得たりする作業に時間を費やさなくてはなりません。オートメーション、サポート、トレーニング、テストなど、ユーザーがPAMを導入しやすくするための対策を強化すべきです。

重要な課題は、PAMが作業の妨げになるとき、開発者とIT管理者がPAMをためらう傾向にあることです。

クラウドの複雑化

Amazon Web Services (AWS)、Microsoft Azure、多くのSoftware as a Service (SaaS)アプリケーションなどのクラウドサービスの登場に伴い、IDアクセス管理(IAM)も変化しています。事業体では、これまでActive Directoryを中心にデータを配備していましたが、それもフラグメント化されつつあります。DevOpsによるInfrastructure as a Service (IaaS)環境では、マシンおよびサービスのIDが主流に なっています。

 

PAMも形態を変えつつあります。マルチクラウド管理機能予備軍と同様に、クラウドPAMは、ファブリック内で今も現役のWindowsや*NIXサーバーに加え、クラウドネイティブのアプリケーション・プログラム・インターフェイス(API)、DevOps、コンテナー、サーバーレス・コンピューティング・モデルをサポートする必要があります。急激な変化が進む中、IAMとPAMはより大規模で運用しなければなりません。

リスクは高まっています。最近起こった、Capital OneのAWS S3ストレージバケットからデータが窃取された事件3をはじめ、度重なるデータ漏洩は、マルチクラウド・インフラストラクチャの管理をシームレスに自動化する必要があることを浮き彫りにしました。

PAMクラウドギャップ

AMおよびPAMマルチクラウド管理機能が未成熟であるため、顧客は複数のクラウドギャップに悩まされています(図2))。

Applying Privilege -2

JIT PAMはまだ少し先

AWS AssumeRole4では, ユーザーがAmazonのセキュリティ・トークン・サービス(STS)から一時的にセキュリティ・アクセス・トークンや資格情報を取得できます。このようなサービスは、新しいアクセスモデルを提示しています。また、MicrosoftがサポートするJITアクセスでは、特権が「常に有 効」ではないため、IT攻撃領域(アタックサーフェス)を大幅に縮小します。JITアクセスは、最小特権の原則を象徴するテクノロジーです。

PAMをIGAに統合すべきか?

実行時にユーザーが役割を担う命令を与えるた め、JITアクセスを管理するソリューションが必要になります。管理者や開発者には、サーバーにログインしたり、新しいコマンドを実行したりするたびに、手動ワークフローによる承認プロセスへの協力を期待することはできません。

しかしながら、リスクに基づいた自動意思決定により、アクセスを許可または却下するために必要なロール、資格、IDを深く理解しているのは、 (PAMではなく)IAMのIGAコンポーネントです。PAMとIGAとの統合は浅くなる傾向にあります。IGAおよびPAMのベンダーは、より密接に統合するか、あるいは互いにより多くのクラウド対応機能を実装する必要があります。

特権付きサービスアカウントを管理するためのDevOpsパイプラインとの統合

IGAにより、アクセス要求プロセスをほとんどシームレスにすることができれば、SaaS、Platform as a Service (PaaS)、IaaS環境において、ユーザーアカウント用にJIT PAMを提供することで、リスクを大幅に下げることができます。常に有効なロールや長期にわたって使用されるトークンが撤廃されるため、Capital Oneの事例のようなクラウドデータ漏洩は発生しにくくなります。

IaaS環境にはもう少し工夫が必要になります。まず、IGA/PAMは、DevOpsをリスクに基づいたIDガバナンスモデルに準拠させることをサポートしなければなりません。ほとんどの機密アプリケーション用 DevOpsユーザーアカウントは、関連するリスク基準の照合後、昇格された特権のみを取得する必要があります。また、アクセスは特定の機能に制限する必要があります。

次に、IGA/PAMは、ユーザーとサービスアカウントアクセスを両方管理するための包括的アプローチを導入しなければなりません。サービスアカウント認証は、APIキーまたは外部のシークレット管理機能により制御される必要があります。サービスアカウント特権も、IGAシステムによって認証されたロールによって制御できるでしょう。このようなコントロールでは、Ansible、Chef、JenkinsなどのDevOpsパイプライン・オーケストレーターと統合するために、クラウドPAMソリューションが必要になります。

最後に、IGA/PAMは、「反脆弱性」アーキテクチャモデルをインストールする機能を持たなければなりません。クラウドを拡張/縮小するため、最終的にIGA/PAMをクラウドで実行する必要があります(現状ではほとんどがオンプレミス型)。現在のジャンプホストやエージェントなどのコンポーネントは、コンテナー化し、マイクロサービスベースとして、DevOpsに対応(少なくとも大規模なセルフコンテナーシステム環境)する必要があります。

結論

ITアクセス、IGA/PAMの統合、反脆弱性アーキテクチャは、PAMをクラウドへと拡張し、これまでのPAM採用の障壁を乗り越えるという希望を業界にもたらします。克服すべき実用上の課題はまだ山積しており、アーリーアダプターがプロジェクトを拡大しすぎるリスクも存在します。しかし、クラウドIGA/PAMの検討に遅れを取ると、現在のフラグメント化され過剰な権限が付与されたIAM環境がこれからも続き、それどころかシステムの脆弱性が高まる可能性すらあります。担当者は、数年後に統合クラウドIGA/PAM機能を構築するため、楽にできることや最重要システムのリスク低減を模索することから始めるべきです。

脚注

1 Blum, D.; “Privileged Account Management (PAM) Is Necessary, But Deploying It Stinks,” Security Architects Partners, 6 May 2015
2 Said in a conversation with the author
3 Blum, D.; “Did Capital One Respond Well to an ‘Erratic’ Data Breach?” Security Architects Partners, 10 September 2019, https://security-architect.com/did-capital-one-respond-well-to-an-erratic-data-breach/
4 Amazon Web Services (AWS), “AssumeRole,” https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

Dan Blum, CISSP, Open FAIR

Security Architects Partnersの主席コンサルタント。サイバーセキュリティ、リスクマネジメント、クラウドコンピューティング、ID管理の分野で国際的にも知名度の高い専門家として、セキュリティ評価の実施や顧客のリスクマネジメントプログラム、ID管理、セキュリティ戦略、アーキテクチャ・ロードマップの策定などに尽力しています。過去には、Gartnerでバイスプレジデント兼任の優れたアナリストとして、Golden Quillアワードを受賞した実績を有します。Blum氏はISACA®、IDPro、Cloud Security Alliance、Kantara Initiative、OASISなど、数々の業界団体に参加してきました。また、近々『Rational Cybersecurity for the Business』を上梓する予定です。