inthisfucking.world

💩🌎

HomePostsAbout

設定すべきGCPの組織ポリシー

GCPには組織ポリシーというものがあります。これを利用することで、特定の設定を強制したり制限することができます。

この記事では、利便性よりもセキュリティーを最優先にする場合に設定すべき組織ポリシーを羅列します。尚、個人でGCPを使用する場合よりも、大企業にてGCPを使用する場合を想定します。

この羅列は、2022年9月時点で利用可能な制約を元に作成しました。組織ポリシーの制約は、随時追加されています。最新の制約の一覧は、組織のポリシーの制約を参照ください。

TODO: 組織ポリシーには、組織ポリシーを設定した後に変更しようとした値に対してのみ適応されるものと、過去に設定されている値に対しても適応されるものがある旨を記載する。

前提

この記事では、以下を前提とします。

設定すべき制約の一覧

constraints/iam.allowedPolicyMemberDomains

この制約は、ドメインの一覧を指定することで、組織リソースの中では特定のドメインに属するユーザのみにIAM roleを付与することができようにします。

example.comをドメインの一覧として指定した場合、user-1@example.comにIAM roleを付与することはできますが、ihopethisuserdoesntexist@gmail.comにIAM roleを付与することはできなくなります。

GCPにおいてセキュリティを担保する際に、一番大事なのはユーザに対する権限管理です。知らない間に、会社のドメインに属さないユーザにIAM roleを付与してしまうことほど恐ろしいことはないでしょう (例えそれが社員が所有する@gmail.comのアカウントであっても)。

GCPを利用するにあたって、最も重要な組織ポリシーといっても過言ではありません。組織リソースに対して、会社で使用するドメインのみを指定しましょう。

constraints/essentialcontacts.allowedContactDomains

この制約は、Essential Contactsに登録するユーザの属するドメインの一覧を指定することで、指定したドメインに属するユーザのみがEssential Contactsに登録できるようにします。

GCPは、色々な事柄に関してユーザにメールを送ります。例えば、料金の請求やセキュリティに関して、ユーザに連絡するべきと判断した場合にメールを送ります。その際に、Essential Contactsを利用すると、どういう事柄に関してはどのユーザにメールを送るかを設定できます。連絡の内容によっては、会社の社員のみが知るべき内容も含まれるでしょう (特に料金の請求に関するもの)。

この制約を利用することで、GCPの利用に関するメールを会社のドメインに属したユーザのみに送信することができます。上記の制約同様、@gmail.comのアカウントなどにそれらの連絡のメールが送信されないように、組織リソースに対して会社で使用するドメインのみを指定しましょう。

Essential Contactsにて、メールの受信者が指定されていない場合は、fallbackとしてIAM roleの付与の状況からメールの受信者を判断します。詳しくはEssential Contactsのページを参照ください。

constraints/compute.vmExternalIpAccess

この制約は、GCEのインスタンスの一覧を指定することで、外部IPの付与を許可されたGCEのインスタンスの一覧を指定できるようにします。通常は、空の一覧を指定することで、全てのGCEのインスタンスに対して外部IPの付与を制限します。

基本的には、GCEのインスタンスに外部IPを付与する必要がある状況はありません。web appを公に公開する際であっても、External HTTP(S) Load Balancerに外部IPを付与し、そのlbのbackend serviceとして内部IPのみを持ったGCEのインスタンスを指定する場合が殆どでしょう。

組織リソースに対して、空の一覧を指定しましょう。どうしてもGCEのインスタンスが外部IPを持つ必要がある場合は、外部IPが必要なGCEのインスタンスが属するプロジェクトのみに対して、そのGCEのインスタンスを指定しましょう。

踏み台サーバとしてGCEのインスタンスを使用する場合でも、IAPを使用することで外部IPは必要ありません。詳しくはIAPのページを参照ください。

constraints/iam.disableServiceAccountKeyCreation

この制約は、真偽値を指定することで、service accountのkeyの作成を有効化若しくは無効化できるようにします。

GCPの中でservice accountを使用する場合は、基本的にはservice accountのkeyを作成する必要はありません。組織リソースに対して、真を指定して無効化しましょう。開発環境でどうしても必要な場合は、開発環境のみに対して有効化することを考えましょう。

開発環境であっても、自分が使用するGoogle Accountに対して、開発で使用するservice accountを使用する権限を付与することで、そのservice accountのkeyを開発環境にダウンロードする必要を無くせます。こちらのページを参照ください。

constraints/iam.disableServiceAccountKeyUpload

この制約は、真偽値を指定することで、service accountのkeyをアップロードすることを有効化若しくは無効化できるようにします。

あまり知られていませんが、service accountにはGoogleが管理するものとユーザが管理するものが存在します。ユーザが管理するものに関しては、ユーザがservice accountの秘密鍵を管理し、その秘密鍵の対となる公開鍵をGCPにアップロードします。この制約は、それを有効化若しくは無効化できるようにします。

通常は、ユーザが管理するservice accountが必要になることはありません。組織リソースに対して、真を指定して無効化しましょう。

constraints/gcp.resourceLocations

この制約は、場所の一覧を指定することで、組織リソースの元で作成されるGCPのリソースが存在する物理的な場所を制限できるようにします。

準拠する必要のあるコンプライアンスによって、データを保存する物理的な場所に制限があることはよくあるでしょう。この制約を使用することで、指定した場所以外でGCPのリソースが作成されることを制限することができます。

組織リソースに対して、意図的に使用したい場所の一覧を指定しましょう。

指定する値がregionかmulti-regionかによって、使用する値が多少異なります。詳細はこちらのページを参照ください。

constraints/compute.restrictLoadBalancerCreationForTypes

この制約は、ロードバランサーの種類の一覧を指定することで、作成可能なロードバランサーを制限できるようにします。

上記の他の制約で、GCEのインスタンスに外部IPの付与を制限できる旨を記載しましたが、GCEのインスタンスに外部IPが付与されなくとも、ロードバランサー経由でGCEのインスタンスにアクセスを可能にすることができます。この制約で、その可能性も制限しましょう。

組織リソースに対して、EXTERNALのprefixのあるロードバランサーの一覧を指定し、それらをdenyしましょう (若しくはINTERNALのprefixのあるロードバランサーの一覧を指定してallow)。production及びstagingの環境においては、外部からのアクセスが必要な場合もあるでしょう。その場合は、それらの環境のフォルダに対して、必要なロードバランサーを許可しましょう。

constraints/compute.skipDefaultNetworkCreation

この制約は、真を設定することで、プロジェクトを作成した際にデフォルトのVPCが作成されることを制限できるようにします。

デフォルトのVPCは必要ありません。組織リソースに対して、真を設定してデフォルトのVPCの作成を制限しましょう。

constraints/storage.uniformBucketLevelAccess

この制約は、真偽値を指定することで、GCSのバケットに対する権限管理の方法をuniform accessに制限できるようにします。

GCSのバケットは、バケットの中のオブジェクトごとにアクセス権を設定する方法と、バケットに対してアクセス権を設定する方法の二つが存在します。前者の場合、バケットの中の奥の奥にあるフォルダだけ公に公開されていたという状況になり得るため、非常に管理が煩雑です。特に制限がない場合は、後者の方法を採用しましょう。

組織リソースに対して、真を設定してuniform accessを強制しましょう。

constraints/storage.publicAccessPrevention

この制約は、真偽値を指定することで、GCSのバケット及びオブジェクトが公からアクセスされるように設定されることを制限できるようにします。

上記の制約から分かるように、GCSのバケットやオブジェクトが公になってしまって情報漏えいすることが非常に多いのでしょう。この制約を利用することで、そもそも公からアクセスできる設定にすることを防ぐことができます。勿論、実際に公にしたい場合にもそれができなくなります。

GCSのバケットやオブジェクトを公からアクセスさせる場合は殆どありません。組織リソースに対して、真を設定して、そもそも公からアクセスできるような設定にできないようにしましょう。

結論

GCPの組織ポリシーは、うまく活用すると非常に便利です。この一覧を参考に、セキュリティの向上に貢献できれば嬉しいです。