• tech系
11分で読める

Cloud OnAir 第23回 ~「GCP で構築するセキュアなサービス。基本と最新プロダクトのご紹介」~まとめ

こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。

こんにちは。クラウドエース編集部です。

【毎週木曜 18:00~19:00】に、Google 社のエンジニアが、Google Cloud Platform の製品、サービスや導入事例等について解説する番組が放送されています。
ユーザー参加型の生放送番組 となっており、視聴者からのリアルタイム Q&A も受け付けています!

この記事では、動画を見逃した方や、見る時間が無い方向けに、要点をかい摘まんで紹介したいと思います。

今回の OnAir ではクラウドにおいて考えなくてはいけないセキュリティについてと、最新の Google Cloud Platform の セキュリティ関連のプロダクトについてをご紹介する内容になっています。

講師は、Google Cloud カスタマーエンジニアの 明関 賢太郎 さんです。

今回のテーマ:GCP で構築するセキュアなサービス。基本と最新プロダクトのご紹介

今回の OnAir の放送ではクラウドのセキュリティの基本についてと Google Cloud Platform の最新のセキュリティ関連プロダクトのアップデートについて紹介する内容となっています。

アジェンダ

  • Google Cloud のセキュリティの基礎
  • クラウドを安全に利用するために
  • IAM と BeyondCorp
  • まとめ

Google Cloud のセキュリティの基礎

Google: a leader in public cloud platform native security

Google は 第三者機関 によって、数あるパブリッククラウドサービスプロバイダーの中でも、セキュリティの面でリーダーとして評価されています。

セキュリティがクラウドの長所に – エンタープライズでクラウド利用が増加している理由

今まではクラウドのセキュリティを不安視する方が多かったですが、セキュリティを理由にクラウドを選ぶ人も増えてきています。

不正な侵入をクラウドを利用することで防ぐ

Google はクラウドを利用することで、スパムメールや悪意のあるメールのフィルタリング、DDoS 攻撃に耐えうる回線の帯域の確保、悪意のあるコンテンツを含む URL からデバイスを保護、などの不正な侵入を防いでいます。

GCP Strategic Focus Areas

Google Cloud は以下の4つのフォーカスエリアを以って、クラウドをセキュアに保っています。

セキュリティと “信頼” についての考え方

Google は以下の考え方に基づいて、セキュリティと信頼を高める努力をしています。

検証可能なセキュアな基盤

1. の 「検証可能でセキュアな基盤を作る」という考え方について詳しく見てみましょう。

Google はハードウェアなど、暗黙的に信頼しなくてはいけないものはなるべく自前で用意して、セキュアな基盤を実現するためのそれぞれの階層構造に対してしっかりとしたものを作ることを考えています。

Google はセキュリティを守りながら、ビジネスを加速させていくという観点でクラウドを使ってもらいたいと考えています。

クラウドを安全に利用するために

責任共有モデル

責任共有モデルは ユーザーと Google と両方で安全なシステムを作る、という考えです。

  • ユーザーはインフラの上で構築されるアプリケーションをユーザー自身で保護する。
  • Google は安全なインフラを提供し、インフラを保護する。

このように責任を共有するモデルを取り、ユーザーと Google の両方でクラウドの安全な利用の実現しています。

クラウドセキュリティの責任は、お客様と Google で共有

責任共有モデルについて、Google Cloud のサービスによって、どこからどこまでがユーザーの責任で、どこからがどこまでが Google が管理する責任であるのかということが変わってきます。

下の図は、Google Cloud Platform の IaaS (Infrastructure as a Sevice)、PaaS (Platform as a Service)、SaaS (Software as a Service) のサービスにおいて、ユーザー(青)と Google(緑)の管理する責任の範囲について表したものです。

Google 独自の設計のハードウェア

責任共有モデルの「Google はインフラを保護」という部分を掘り下げて見てみましょう。

Google は一般的にはソフトウェアの会社と思われていますが、ハードウェアも独自で開発をしています。
Titan と呼ばれる Google 製のカスタムチップを使うことで、Google が認証したソフトウェアしか動作しないようにしたり、サーバ、ストレージ、ネットワークに関してもなるべく自分たちで設計に関わることでリスクを減らす対応を行っています。

Google ネットワーク

Google は世界中に張り巡らされた独自のネットワークを持っています。これらの独自のネットワークが Google Cloud の高いセキュリティにも貢献しています。

全てのデータをデフォルトで暗号化

Google Cloud で保存されているデータは基本的に全て暗号化されているので、万が一データが取られてしまっても中身が分かってしまうことはありません。
暗号化という部分について細かく見てみると、例えば、1つのファイルがあったとして、そのファイルはチャンクに(細かく)分割され、それぞれを異なる暗号鍵で管理する仕組みになっています。

Google 内のサービス間通信も暗号化 – Application Layer Transport Security (ALTS)

ATLS(Application Layer Transport Security)という Google のサービスに最適化した独自のシステムを使って Google の中での通信を暗号化しています。ですので、仮に有能なハッカーが Google 内の通信を見ることがあっても、通信が暗号化されているので情報が漏れることはありません。

データの削除

Google は最近、データ削除のためのステージ構造を ホワイトペーパー として文書の形で公開しました。
Google は以下の4つのステージを経ることで、安全にデータを削除しています。

主な支援機能の一覧

続いて、責任共有モデルの「ユーザーはアプリケーションを保護」という部分を掘り下げて見てみましょう。

Google Cloud は主に以下の5つのカテゴリの支援機能を提供しています。ユーザーはこれらの支援機能を利用して、サービスをセキュアに構築できるようになっています。

Shielded VMs

最近導入された Shielded VM は rookit や bootkit などの悪意のあるソフトウェアに対しての耐性を高めるものになっています。

Binary Authorization

Binary Authorization は GKE(Google Kubernetes Engine)の新機能で、検証されたイメージだけ展開、デプロイできる機能になっています。

CI/CD 時において、Binary Authorization を使うことにより、デプロイする前にシグネチャを入れて、検証しなければデプロイできないようにすることができます。こちらはオープンソースの代替手段を使ってでも実現できますが、Binary Authorization を使うことにより、簡単に Google Cloud の中で運用できるようになります。

Container Registry 脆弱性スキャン

Google Cloud ではコンテナの中の脆弱性スキャンをするサービスも行っています。

Container Optimized OS

セキュアで軽量なコンテナ用の OS も用意されています。

Cloud HSM

続いて、暗号鍵について見てみましょう。

先程から「暗号化」というキーワードが出てきていますが、暗号化する鍵を管理するにはどうするのか、Google ではなくて自分たちで暗号鍵を管理したい、というユーザーの声も出てきます。これに答えるために、Google Cloud は Cloud Key Management という暗号鍵を管理するサービスを提供しています。Cloud HSM はセキュリティの要件の高い顧客向けのサービスで、よりセキュリティ基準の高い暗号鍵の管理を実現できます。

Cloud Armor(WAF, DoS 対策を備えた GSLB)

Cloud Armor というサービスを使って、SQLi や XSS からの防御、DDoS の対策、IP のホワイトリスト・ブラックリスト化、地理ベースのアクセスルールなどを設定することで、セキュアなサービスの構築を実現できます。

VPC Flow Logs

Cloud Armor が園からのリクエストや攻撃に対してのセキュリティ機能であるのに対して、VPC Flow Logs は VPC 内部の通信フローログを取得・集計できる機能です。こちらは、社内の中で不正な動きがないかどうか、ということを監視する用途で使用できます。

悪意ある内部ユーザーへの対策 VPC Service Control

クラウドでは API 経由でのアクセスが基本になりますが、VPC Service Control を使うことにより、認証されているユーザーであっても、定義されたゾーン(ペリメータゾーン)の外部からはアクセスできないようにすることができます。

Access Transparency

Google は基本的にユーザーのデータにアクセスすることはありませんが、ユーザーの合意の元でユーザーのデータにアクセスすることがあります。(例:Google のサポートチームがユーザーの環境で起きているエラーを確認しなくてはいけないとき、など)
Access Transparency はそのようなときに、Google が ユーザーのデータにアクセスした手段や理由をログとして表示するための機能になっています。

IAM と BeyondCorp

Identity and Access Management (IAM) とは

誰が・どういう操作を・何に対して・どういう条件で操作できるのかを指図するためのものです。
「誰が」には「Google アカウント」や「Google グループ」や「サービスアカウント」などが指定できます。
「どういう操作を」には「BigQuery の操作ができる」や「コンテナベース開発ができる」などが指定できます。
「何に対して」には「プロジェクト」や「リソース」を指定できます。
そして、それぞれを「どのような条件下で」操作できるかを指定することができるのが IAM です。

グループに対して役割を割り当てる

例えば、「太郎さん(Google アカウント)が所属するデータサイエンティスト(Google グループ)はプロジェクト A のインスタンスの管理とプロジェクト B の BigQuery の利用が可能である」という風に IAM を設定することが可能です。
逆に言えば、設定されている役割以外の操作はできません。

階層レベルごとに権限/ロールがある

IAM の概念として、何に対してを掘り下げて説明します。
まず、「組織」というものがあり、その配下に「プロジェクト」とそのプロジェクトの集合体である「フォルダ」(会社でいえば部署などが該当することが多いと思われます)が存在しており、さらにその配下に「VM」や「ストレージのバケット」や「データセット」などの「リソース」が存在しています。
これらの単位でアクセスの管理を行います。

Secure LDAP

先月の Next ’18 で発表した新しいサービスです。
今までは様々なサービスに対してそれぞれのアカウントを発行するなどの管理の手間がありましたが、G Suite アカウントや Cloud Identity と連携し、LDAP のようにユーザーのアカウントやディレクトリへのアクセス権限の一元管理が可能になります。

Context-Aware Access

ユーザーのデバイスや場所、そのほかの属性に基づいて詳細なアクセスポリシーを設定するための新機能です。
IAM の「どのような条件下で」を設定できるのが Context-Aware Access です。

進化するリモートアクセスとセキュリティモデル – BeyondCorp

BeyondCorp は特定の製品ではなく Google のセキュリティに関する考え方の提案です。

前提としてゼロトラスト(全てのネットワークを信頼しない)というものがあり、ユーザーの認証とデバイスの認証と厳密な権限設定により管理ができるというものです。これらを管理することにより、VPN 接続なしで社外から社内へとセキュアに接続が可能です。
Google は Identity-Aware Proxy というサービスとして提供しています。

BeyondCorp: Google が目指すセキュアなアクセス~ VPN が不要な状況に応じた安全なアクセス~

Google Cloud は2段階認証によるユーザーのログインを制御し、GCP や G Suite 内部ではログインをしたユーザーが何ができるかを制御し、通信の暗号化により VPN がなくても安全な通信を確保します。

Google’s BeyondCorp のコンポーネント

コンポーネントは「ポリシー」と「属性」と「アプリケーションとデータ」の3つのコンポーネントに分けて BeyondCorp は考えられています。
「ポリシー」とは「誰がどういうことができるのか」を定義して適用することです。
「属性」では「ID、デバイス、位置などのユーザーのリクエスト状況」を理解することです。
「アプリケーションとデータ」では「どういうアプリケーション、データなのかということ」を理解することです。
これらが、BeyondCorp のセキュリティを守るために必須で考えるべきことです。

様々なリスクへの対応

リスクとして考えられるものとして「従業員」「デバイス」「ルール」「プロキシ」「クラウドサービス」の5つが考えられます。
それぞれ、「従業員」が本物のユーザーなのか、「デバイス」が接続を許可されたものなのか、「ルール」は特権アカウントか、ネットワークパスに脆弱性はないか、「プロキシ」ではこのユーザーはアプリケーションにアクセス可能かなどです。

クラウドと ID 管理 – Google Cloud – BeyondCorp の主な特徴

上記のリスクに対して、BeyondCorp では、「従業員」に対して強力なアイデンティティと強いフィッシング耐性、「デバイス」では許可されたデバイスからの接続なのか、TLS での認証が行われているか、「ルール」ではポリシーの集中管理などがあります。
これらがきちんと管理されることにより、セキュアな世界を実現するのが BeyondCorp の考え方になります。

BeyondCorp で VPN 不要かつセキュアな世界

先ほどのモデルを具体的に説明しますと、BeyondCorp は次のスライドのようなサービスで実現されます。

まとめ

本日は4つのことについて説明を行いました。

  • セキュリティを確保してビジネスを加速する
    クラウドを利用する理由としてセキュリティがポイントとなっている。
    適切にクラウドが提供するセキュリティを利用することで、安全なサービスを構築しましょう。
  • Google が提供するセキュアなインフラ
    Google がどういったインフラの取り組みをしているかを紹介しました。
    データの暗号化・ネットワーク通信の暗号化に対してセキュリティホールのないインフラを構築しています。
    Google Cloud は全方位にセキュアなインフラを作成しています。
  • 開発時の留意事項
    責任共有モデルを元に、ユーザーが気にしなくてはならないところを説明しました。
  • 最新動向の紹介
    IAM と BeyondCorp を紹介しました。

最後にひとこと

いかがでしたでしょうか。
以上が「GCP で構築するセキュアなサービス。基本と最新プロダクトのご紹介」のまとめでした。
Google のセキュリティへの関心の高さが伝わる内容だったのではないかと思います。Google はあらゆるプロダクトにおいて、セキュリティを強固にするような取り組みをし続けています。クラウドをまだ導入していない方々も是非この機会に Google Cloud Platform の導入を検討してはいかがでしょうか。

次回の放送は、「最新版 GCP ではじめる、サーバーレスアプリケーションの開発。」です。
サーバーレスにすると、面倒な基盤インフラストラクチャの管理に時間をとられずにコードの作成やデプロイを行い、開発者はアプリケーションの開発に専念することができます。Cloud Functions や App Engine、 Pub/Sub などといった GCP のサーバーレスサービスに適用させる DevOps 対応なソリューションについてをご紹介する内容になっています。

それでは、次回も 11/8(木)18:00 にお会いしましょう。

参考リンク

番組視聴

Cloud OnAir の放送は、今回分含め、バックナンバーも全て Cloud OnAir のページで視聴できます。
スライドと合わせて進行する解説を、是非ご覧ください!
今回の番組視聴ページ URL:https://cloudonair.withgoogle.com/events/cloud-onair-japan-q4-2018/watch?talk=tky_gcp_q4

SlideShare

今回の動画で説明に使用されたスライドについても、SlideShare でいつでも閲覧可能です。
登場した用語について振り返りたい、用語同士の関係性を確認したい等、大変参考になります!
スライド URL:https://www.slideshare.net/GoogleCloudPlatformJP/cloud-onair-gcp-2018111

この記事を共有する

合わせて読みたい