🔒

クラウドでもsuが出来る! GCPにPAM(特権管理)がついに登場

2024/05/11に公開

Google Cloud

Security

IAM

tech

はじめに

Linuxの良い所の一つにsuやsudoと言った特権管理の仕組みがあります。普段は通常アカウントで入って、例えばインストールなどの特権作業が必要な時だけsu/sudoで一時的な権限昇格が可能ですし、/etc/pam.dで誰がどのユーザにスイッチ出来るかなどは細かく制御できます。

一方で、クラウドの権限管理は悩みの種で、誤操作が怖いので普段はRead Onlyの権限にしておきたいのですが、手軽に権限を昇格する方法がありません。なので、別の管理者ユーザを作って、そちらでログインしなおしたり、それを半自動化するCyberArkやBeyondTrustといったPAM系ソリューション、あるいは最近流行りのCIEM(PAM機能を持つもの)を導入する必要がありました。

Azureでは結構以前からPIM(Privileged Identity Management)がネイティブで組込まれており非常に便利だったのですが、GCPでは昔はそうした機能が無かったので、以下のように自作をしたこともあります。

最近は、公式みずからCloudRunにデプロイするOSSを出していました。

今回、4月に開催されたCloudNextでネイティブのPAM(Privileged Access Manager)がプレビュー版で公開されたので、誰でも簡単に使えるようになりました。早速試してみます。

TL;DR

GCPにネイティブのPAMが登場
JIT、承認、監査ログと基本的な事は問題無し
承認なしの資格も作れるので個人サービスやスタートアップにも最適

特権管理に求めること

特権管理、つまりPAM (Privileged Access Manager)に求めることは、最小権限の原則 (Principle of Least Privilege)を実現する事です。

そのため、一時的な権限昇格、すなわちJust-In-Time(JIT) Accessは必須機能です。加えて「誰が昇格出来るのか？」を管理できることも重要です。また、多くの企業では特権作業の申請の証跡を残したり、事前承認をしたい事も多いでしょう。特権作業に、承認フローを必須にする事で、マルウェアによるアカウント乗っ取りや悪意のあるオペレータによる不正なオペレーションのリスクを大きく下げる事が出来ます。

また、シナリオ毎に必要な権限に昇格することで、とりあえずOwnerとか最高権限を与えるという運用では無く、普段の運用向けの権限ロール、NW周りの権限ロール、セキュリティ周りの権限ロール等々、比較的小さな権限にしても現実的な運用が少数のオペレータでもやりやすくなります。これはオペミスの防止にも役立つのでオペレータの安心にも繋がりますよね。

さらに人によっては、そうした 監査ログ(Audit Logs) をレポートしたい人も居ますよね？　今回は、それらのPAMに必要な機能がどこまで実現されているのか？　という点で検証してみたいと思います。

基本的なシナリオ

まずは承認権限をもったkoduki-admと、通常はViewer権限しかもたないkodukiというオペレータの想定で、開始します。

まずは準備

まずはPAMを有効にします。Cloud IAMの画面にいくと以下のようにPAMという項目が増えているので、それをクリックしてください。

初回は以下のような画面になると思うので、セットアップをすすめてください。

セットアップが終わると以下のような画面になります。

利用資格を作る

まずは利用資格(Entitlements)を作ります。これは申請可能なユーザ、承認可能なユーザ、対象のロールがセットになったもので、オペレーションのユースケース毎に作る事になります。

まずはアサインするロールの詳細を決めます。OwnerやEditorなどの基本ロールは設定できませんが、複数のロールを設定する事は出来ます。また、カスタムロールも使えるので広範囲にわたる良く使う権限ならカスタムロールにするのも便利です。

IAM Conditionsにも対応しているので、アクセス先のリソースを特定のタグが付いたものに限定したり、社内からアクセスされてる時のみだけに限定したり、より細かな制御が可能です。

次に、リクエスターを指定します。今回は個別のアカウントでは無く、gcp-cmn-developers@nklab.devというグループを指定しました。

GCPではロールは個別アカウントにもグループにも紐づけられますが、グループに紐づけるのがベストプラクティスです。このグループは厳密にはGCPの機能というよりCloud Identity (Google Workspace)の機能で、GCP使ってると自然とFree Tierで使ってるはずです。ただ以前はグループの管理がAdmin Consoleからのみで地味に不便だったのですが、最近はGCPに統合されたので、以下のように組織のページから管理する事が出来ます。

続いて承認者の設定。ここは管理者を入れておきます。

最後にNotificationの追加です。権限昇格したらメールを出す、とかが出来るので、特に普段使わない強力な権限に昇格する際は、ML等に流しておくと良いかと思います。

これで、利用資格は作成できました。実際に権限昇格フローを回してみます。

権限付与リクエストをしてみる

まず、Viewer権限しか持たないkodukiでGCEを作ろうとすると、当然以下のように権限エラーになります。

なので、以下のようにPAMのページに飛んで、利用資格を申請します。

先ほど作成した利用資格が見えますね。権限付与をリクエストしてみます。理由と利用時間を指定します。利用時間は最大で利用資格を作る時に決めた数字を超える事はできません。

権限付与を承認する

つづいて、承認権限をもつkoduki-admでPAMにアクセスすると以下のように権限付与の申請が来ているのが確認できます。

これをApproveすれば承認です。理由が不適当な場合はDenyしてください。今回は承認します。

権限の付与を確認する

では、kodukiで権限が付与されたかを確認してみます。PAMの権限付与(GRANTS)のページから以下のように申請した権限付与リクエストが承認されたことが分かります。

GCEのページに行って実際に作れるようになったのかを確認します。

無事、インスタンスの作成が出来るようになっていますね！

監査ログの確認

PAMを使って、権限付与のためのワークフローを回す事が出来ました。では、その証跡は確認出来るのでしょうか？
実は、これもPAMのページから簡単に確認できます。Auditタブに以下のように履歴が出ます。

リンクをクリックすれば個別の申請の詳細も確認できます。

ただ、CSVやExcelにExportすることは現在はこの画面から出来なさそうでした。他にもSOCなどにもこうしたログは流したいですよね？　安心してください。これはGCPのAudit Logsとして記録され、この画面は単にPAM向けのものを表示するダッシュボードなので、Cloud Loggingに普通に記録されています。

Log Exploreから以下のように見る事が出来ますし、ここからCSV等へのExportやGCSなどを経由して各種Security Monitoringにログを連携することも、いつものGCPの手順で行う事が出来ます

ワンオペ体制でのシナリオ

GCPのPAMで、基本的なシナリオが実現出来る事は分かりました。ただ、個人開発やスタートアップのようなワンオペないしは少数の運用だと、第三者承認とか現実的な運用は困難ですよね？

前提的に監査や承認フローは重要ではないかもしれませんが、やはり通常は比較的低い権限で入って、一時的に特権に昇格、という運用が安心なのでPAMは欲しいものです。というわけで、そうしんたワンオペシナリオも実現できるか検証してみました。

実は簡単で 「承認無しで有効化」 にチェックを入れるだけです。こうすると承認者を指定することなく利用資格の作成が完了します。

kodukiユーザの画面からは以下のようになります。

リクエストをすると以下のように即座に資格がActivateされました。

この状態でももちろん監査ログは残ります。

そのため、ワンオペ運用時はもちろんですが、この設定は資格毎に分ける事が出来るので、重要な権限のみは承認を要求するが、普段使いのロールへの昇格は特に承認を必要としない、などの柔軟な運用を実現する事が出来ます。

まとめ

個人的にはついに待望のPAMがGCPに来た！　という感じなので、感無量です。
PAMを使うことで、今まで気持ち悪かったユーザアカウントと管理者アカウントをそれぞれ作って切り替える運用を辞める事が出来るし、セキュリティ的にもガバナンス的にも大きく向上します。

オンプレミスやマルチクラウドの場合は、環境を跨いで管理するサードパーティのソリューションが欲しくもなりますが、単独のクラウドで完結しているならクラウドネイティブのPAMを使うのが一番手っ取り早く運用も楽なので良いですね。

それではHappy Hacking!