Google はクラウドを利用することで、スパムメールや悪意のあるメールのフィルタリング、DDoS 攻撃に耐えうる回線の帯域の確保、悪意のあるコンテンツを含む URL からデバイスを保護、などの不正な侵入を防いでいます。
GCP Strategic Focus Areas
Google Cloud は以下の４つのフォーカスエリアを以って、クラウドをセキュアに保っています。
セキュリティと “信頼” についての考え方
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 で保存されているデータは基本的に全て暗号化されているので、万が一データが取られてしまっても中身が分かってしまうことはありません。
暗号化という部分について細かく見てみると、例えば、１つのファイルがあったとして、そのファイルはチャンクに（細かく）分割され、それぞれを異なる暗号鍵で管理する仕組みになっています。
Google 内のサービス間通信も暗号化 – Application Layer Transport Security (ALTS)
ATLS（Application Layer Transport Security）という Google のサービスに最適化した独自のシステムを使って Google の中での通信を暗号化しています。ですので、仮に有能なハッカーが Google 内の通信を見ることがあっても、通信が暗号化されているので情報が漏れることはありません。
データの削除
Google は最近、データ削除のためのステージ構造を ホワイトペーパー として文書の形で公開しました。
Google は以下の４つのステージを経ることで、安全にデータを削除しています。
主な支援機能の一覧
続いて、責任共有モデルの「ユーザーはアプリケーションを保護」という部分を掘り下げて見てみましょう。
Google Cloud は主に以下の５つのカテゴリの支援機能を提供しています。ユーザーはこれらの支援機能を利用して、サービスをセキュアに構築できるようになっています。
Shielded VMs
最近導入された Shielded VM は rookit や bootkit などの悪意のあるソフトウェアに対しての耐性を高めるものになっています。
クラウドでは 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 です。
Google が提供するセキュアなインフラ
Google がどういったインフラの取り組みをしているかを紹介しました。
データの暗号化・ネットワーク通信の暗号化に対してセキュリティホールのないインフラを構築しています。
Google Cloud は全方位にセキュアなインフラを作成しています。
開発時の留意事項
責任共有モデルを元に、ユーザーが気にしなくてはならないところを説明しました。
最新動向の紹介
IAM と BeyondCorp を紹介しました。
最後にひとこと
いかがでしたでしょうか。
以上が「GCP で構築するセキュアなサービス。基本と最新プロダクトのご紹介」のまとめでした。
Google のセキュリティへの関心の高さが伝わる内容だったのではないかと思います。Google はあらゆるプロダクトにおいて、セキュリティを強固にするような取り組みをし続けています。クラウドをまだ導入していない方々も是非この機会に Google Cloud Platform の導入を検討してはいかがでしょうか。
