皆さん、初めまして。
ゼロバンク・デザインファクトリー株式会社(以下、ZDF )にてTechnical Lead をさせて頂いている家壽田(けすだ)です。
弊社から皆さんに技術情報をお届けしていこう、ということで、Blog を開設いたしました。
記念すべき第1号として、私共が主に利用しているGoogle Cloud におけるアクセス制御系機能ついて、Enterprise な環境でCloud を利用されようと考えられている企業のインフラエンジニア、クラウドエンジニアの方々を対象に、概要をご紹介できればと思う次第です。
はじめに
Enterprise 利用を前提とした場合、クラウドセキュリティはとても重要なインフラのファクターの1つとなります。
VM 1つとっても、パブリックなIPアドレスを付与して、どこからでもアクセスできる状態とすると、乗っ取り可能かどうかポートスキャンなどが行われ始めます。
また、1つ何がしかの壁を突破されたとしても、影響が広範囲に及ばないよう、多重に制御を行うことも肝要です。
今回はそういった観点から、重複的なアクセス制御になる部分があることを承知した上で、各機能の概要についてご紹介したいと思います。
今回ご紹介する機能の構成イメージ
組織のポリシー
Google Cloud の自組織(フォルダ/プロジェクト)に対する、統制機能を提供します。
例えば、自社ドメインのアカウント(組織のGoogle アカウント)しかIAM (後述)に登録できないように設定したり、資源(VM など)を作成できるリージョンを制限したり、といったことが可能です。
これにより、意図せずAllUsers がアクセス可能なように設定にしてしまったり、意図しない海外リージョンに資源を構築してしまったり、という誤りを防ぐことが可能となります。
機能は多岐に渡っておりますので、ご興味のある方は公式サイトを参照ください。
また、最近ではカスタムポリシーを作成できるようにもなってきていますので、各社毎に必要な制約を作成して適用することでより強固な制約を適用することができるようになりつつあります。
VPC (Virtual Private Cloud) Service Controls
VPC Service Controls はGoogle Cloud API に対するアクセス制御機能を提供します。
例えば、GCS (Google Cloud Storage)に対するアクセスを会社からアクセスする際に利用されるIPアドレスに制限するといったことが可能で、これにより、意図せぬIPアドレスから自プロジェクトへアクセスすることを防止することが可能になります。
ただし、VPC Service Controlsにはいくつか注意点があります。
1つは、VPC Service Controls の制御対象としているとできないことが発生する点です。
具体的な例として、例えば、Cloud DNS API を制御対象とした場合、一般公開ゾーンが作成/更新できなくなります。
本番環境ではDNS のゾーンが頻繁に更新されることは稀かも知れませんが、開発途上である場合、開発者によってゾーンが更新されるケースもあろうかと思います。
セキュリティと利便性のバランスをどこで取るかは難しい判断となることが多くありますが、考慮の1つとしてこういったケースが存在することは覚えておいて損はないでしょう。
2つに、全てのGoogle Cloud API をサポートしていない点です。
対象外のサービスへのアクセスはVPC Service Controls では制御ができず、極端なことを言えば、ネットカフェなどからでもアクセスできてしまいます。
Google アカウントによる認証があるので、即、無防備になるわけではありませんが、ログイン認証に2FA を強制するなどの施策と合わせてセキュアにしておく必要があります。
最後に、VPC 境界外扱いとなるサービスが存在する点にも注意が必要です。
境界外扱いとなるサービスからのアクセス、その逆に境界外扱いとなるサービスへのアクセスはVPC Service Controls によってアクセス不可扱いとされ、エラーになります。
これに対応するためには、アクセス元のサービスアカウントをアクセス許可対象として登録する必要があります。
ただし、アクセスレベルとして登録してしまうと、そのサービスアカウントを用いると、双方向自由にアクセス可能になってしまいます。
これに対応するため、最近では、内向きポリシー(境界外扱いとなるサービスからのアクセス用)/外向きポリシー(境界外扱いとなるサービスへのアクセス用)に対象のプロジェクトや、Google Cloud API のメソッド単位で許可を行う仕組みも実装されていますので、よりセキュアな環境とされたい場合は、この設定を用いることが望ましいものと思います。
VPC ファイアウォール
VPC ネットワーク単位に適用される一般的なL4 (IP/Port)ベースのファイアウォール機能を提供します。
VPC ファイアウォールが独特なのは、ターゲットとなる範囲をIPアドレスレンジで指定できない点でしょうか。
(具体的に指定できるものは、ネットワーク上のすべてのインスタンス、指定されたターゲットタグ、指定されたサービスアカウントの3つ)
具体的に設定する際は、例えば、VM を作成する時にネットワークタグを設定しておき、そのネットワークタグを対象として通信先の制御を行う、という形となります。
これにより、特定のVM に必要な通信のみ許可する、ということが可能になり、細かい制御はし易くなりますが、ネットワークに携わってこられた方にはちょっと違和感があるかも知れませんね。
Cloud Armor
Cloud Load Balancing にて作成可能なロードバランサーに対するWAF やDDoS 対策、L3 (IP)ベースのファイアウォール機能を提供します。
例えば、VM にてHTTPサーバー機能を提供する場合、VM に直接パブリックなIPアドレスを付与するのではなく、VM をバックエンドとして外部HTTPSロードバランサーを構成し、このロードバランサーにCloud Armor を適用して、WAFを有効にし、必要に応じて、アクセス元IPアドレスの制限をすることでセキュアに構成することが可能です。
Identity-Awere Proxy (以降、IAP)
ここまで紹介してきたサービスとは少し毛色が異なりますが、IAP は、バックエンドのWeb サービスへのアクセスや、VM に対するSSH アクセスに対して、Google アカウント認証を付与する機能を提供します。
また、Proxy として機能するフロントエンドを提供するため、直接制御対象にパブリックなIPアドレスを付与する必要もありません。
尚、制御対象のサービスに対するリソース単位のIAM 権限設定における追加条件を設定することで、アクセス元IPアドレスによる制御も可能です。
ユーザアクセス用としての利用は稀かも知れませんが、システム管理者のアクセス用としての経路として考えると、セキュアで使いやすいサービスであろうかと思います。
IAM (Identity and Access Management)
Google Cloud の各リソースに対するアクセス制御機能を提供します。
通常、Enterprise で利用する場合において、Google Cloud 用のGoogle アカウントはCloud Identity を用いて組織のアカウントとして作成します。
IAM では、Cloud Identity で作成されたアカウント(グループ)に対して、Google Cloud のどのリソースをアクセス可能とするかを紐づけることで、アクセス制御を実現しています。
IAMの制御は、組織 → フォルダ → プロジェクト → リソース、の順で継承される設計になっており、組織にて許可されている権限をリソース単位で不許可とすることは、つい最近まで、できませんでした。
具体的には、組織レベルでアクセス許可が付与されている場合で、あるGCS のバケットのみアクセス不可としたい、といった要求があった場合、組織レベルの許可権限をはく奪した上で、対象のバケット以外に個別にアクセスを許可する設定を行う必要がありました。
これに対応するため、最近、Deny Policy が導入され、特定のリソースのみ不許可に設定することが可能になりました。
運用管理をしていく上で権限管理はとても重要なファクターの1つなので、こういったエンハンスはとても嬉しいですね。
承認済ネットワーク
主にGKE (Google Kubernetes Engine)のコントロールプレーンや、Cloud SQL のインスタンスにアクセスするためのIPアドレスに対するアクセス制御機能を提供します。
許可済ネットワークを設定せず、パブリックなIPアドレスを付与する形でこれらのリソースを作成した場合、どこからでもアクセス可能となってしまいますので、パブリックなIPアドレスを付与する必要がある場合には必ず設定するようにしましょう。
尚、具体的に使われるシーンとしては、kubectl コマンドでGKE に対して定義を投入したり、現在の状況を確認したりというケースや、Cloud SQL に対して、mysql コマンドで接続したりといったケースになりますので、主にシステム管理者向けのアクセス制御のためと考えて頂いて問題ないかと思います。
終わりに
今回は各機能の概要をお伝えしました。
ご要望がありましたら、各機能を深堀りしたご紹介もしていければと思います。
尚、実際に運用していくには、今回ご紹介した機能以外にも外部のSaaS なども併用して、適切な設定が保たれているかを逐次チェックし、セキュリティインシデントが発生しないよう、維持管理し続けるための仕掛けも必要になります。