GCPUG Beginners Tokyo 13 feat. GCPのセキュリティ に参加してきました #gcpug

GCPUG Beginners Tokyo 13 feat. GCPのセキュリティ に参加してきました #gcpug

Clock Icon2019.02.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

中山(順)です

最近、セキュリティネタにアンテナ張りがちです。

今回、セキュリティがテーマということで参加させていただき、内容を整理してみました。

この投稿では、発表内容+後日調べた内容(主に公式ドキュメントへのリンク)という形でまとめてみました。

勉強会概要

募集ページはこちらです。

GCPUG Beginners Tokyo #13 feat. GCPのセキュリティ

GCPのユーザーグループの概要はこちらです。

GCPUG

GCPのセキュリティ

登壇者は、Google Cloud Japan カスタマーエンジニア(いわゆるプリセールス)の森永さんです。

発表時、Google SlideのQ&Aセッション機能を使って質問を随時受け付けていました。

ユーザーからの質問を受け付けて表示する

当日は以下の概要に沿ってGCPのセキュリティについて解説頂きました。

  • Googleのセキュリティの取り組み
  • GCPを支えるセキュリティ
  • GCPでできるセキュリティ対策

なお、資料公開は行わないとのことです。

 

これ以降の記述は筆者が聴講しながらおこなったメモをベースにしたもので、聞き間違いや誤解が含まれる可能性があります。

公式ドキュメントなどは可能な範囲で確認しましたが、正確性を保証することはできません。

サービスの仕様/Google社のステートメント・規約等は公式サイトを参照してください。

 

1.Googleのセキュリティの取り組み

  • Google自体のセキュリティに関する取り組みの紹介
  • 具体例
  • BEYONDCORP 企業セキュリティに対する新しいアプローチ
  • Project Zero
  • Multi Factor Authentication
  • Titan Security Key
  • フィッシング対策
  • Beyond Corp
  • 実際の会社じゃない
  • 概念
  • "Zero Trust"
  • 従来の考え方は「境界」でのアクセス制御が主体
  • VPNゲートウェイなどで認証
  • 社内は安全=従来の考え方
  • 社内NWは安全という暗黙の前提
  • 新たな考え方
  • 社内NWも社外NWも危ない、という前提で設計 (Zero Trust)
  • エンドポイントでユーザー認証とデバイス認証を組み合わせて保護
  • Googleでは、業務で公衆無線LANの利用は禁止されてない
  • CLOUD IDENTITY-AWARE PROXYをサービスとして公開している
  • Googleはたくさんの攻撃を受けてきた
  • その経験を踏まえたセキュリティの取り組みを実施
  • Webサイト
  • Chrome
  • Android
  • Gmail
  • 体制
  • 多数のセキュリティエンジニア
  • Project Zero
  • Googleのサービス等(Googleのサービスや製品に限らない)の脆弱性を特定/分析するチーム
  • 実績
  • Spectre, Meltdown, Heartbleed など
  • その他、Windowsの脆弱性も多数発見
  • 報酬プログラムもやってる

2.GCPを支えるセキュリティ

  • よく聞かれること
  • 「Googleってユーザーのデータ見るんじゃないの?」
  • Google Cloudにおいては違う(後述)
  • Principal
  • Google Cloudにおいては、セキュリティは最優先事項
  • Google(個人向けのサービス)とGoogle Cloud(法人向けのサービス)は「別物」
  • 規約が違うのでよく確認してほしい。
  • B2C向けのサービスにおいてはデータを利用するケースはあるが、個人情報の取り扱いは慎重に行われている。(匿名化など)
  • Google CloudはGCPだけではない
  • GCP以外のサービス
  • G Suite
  • Cloud Identity
  • Chrome
  • Android
  • 認証やデバイス、エンドポイントも含まれる

  • セキュリティは多層防御が基本

  • 物理/インフラのレイヤーにおいても多層的に防御している
  • データセンターの立地
  • データセンターへのアクセス権
  • その他
  • 詳しくはこちら(信頼できるインフラストラクチャ
  • 方針
  • 基本的に自分で作る
  • ハードウェアも作ってる
  • チップ、サーバー、ストレージ、ネットワーク、データセンター、などなど
  • 不要なコンポーネント = 脆弱性などのリスク
  • Reduce "Vendor in the Middle" Risk
  • Googleのグローバルネットワーク
  • 大阪リージョンも提供開始予定
  • データは「デフォルトで」暗号化している
  • データを分割する
  • 暗号化のための鍵も暗号化
  • 保存先も分散
  • 詳細はこちら(Encryption at Rest in Google Cloud Platform
  • 大規模なバッチ適用を利用者が気づくことなく
  • Spectre, Meltdownへの対応は公表前に対策してた
  • Project Zeroの成果
  • Live Migrationを利用してダウンタイムなしで対処した

  • 責任共有モデル

  • IaaS > SaaS で責任を負う範囲は違う
  • 「クラウドセキュリティの責任は、お客様と Google で共有」
  • サービスによって責任分解点が違う
  • 一般的なセキュリティ対策、考慮するポイント
  • インフラ、ネットワーク、データ、アプリケーションなどの各レイヤー
  • エンドポイント、認証
  • コンプラインス・ガバナンス
  • 監視や運用

  • 各種認証を取得

  • ISO27001などのグローバルなの
  • 各国の規制に対応した認証の取得やガイドラインに対応するためのチェックリストなどのリソースを提供
  • 日本の各種ガイドラインへの対応状況
  • FISC
  • 第9版に対応したリファレンスに対応している
  • 3省4ガイドライン(医療情報システム)
  • 総務省、経産省、厚生労働省
  • CSV
  • 製薬会社むけのガイドライン
  • NISC
  • 内閣サイバーセキュリティセンター

3.GCPでできるセキュリティ対策

ここからはGCPの具体的なサービス内容の紹介となります。

権限管理

  • GCPのリソースは階層的に管理される
  • Organization
  • 最上位の概念
  • フォルダ
  • 4層まで作れる
  • 組織図の通りに作るのではなく、権限委譲したい内容に応じて作るべき
  • 権限は継承される
  • プロジェクト
  • 個人でGCPのアカウントを作ると、プロジェクトが1つできる
  • 配下にリソースが作成される
  • Billingをプロジェクトに紐付ける
  • リソース
  • VMなど
  • 詳しくはこちら(Resource Hierarchy
  • 組織ポリシー
  • 組織、フォルダー、プロジェクトに対するポリシーの定義
  • 継承される
  • 許可も出来るし、制限も出来る
  • 制限の例
  • GCE:外部IPの付与を許可するかしないか、など
  • IAM:参加できるドメイン(ユーザーのメールアドレス)を制限、など
  • Organization Policy Constraints

  • IAM

  • IDの管理と権限の付与
  • 権限付与の対象
  • Googleアカウント
  • Googleグループ
  • サービスアカウント
  • 詳しくはこちら(Overview
  • 権限の付与の仕方
  • ユーザーはグループに所属
  • グループにロールを付与
  • ロールにプロジェクトへのアクセス権を定義
  • サービスアカウント
  • GCPの各サービス
  • サービスに対して権限を委譲できる
  • 詳しくはこちら(リソース階層を使用したアクセス制御
  • 許可/拒否するアクションの定義
  • 命名規則
  • サービス名 + リソース + 動詞 (Create, Get, etc)
  • APIとは1:1
  • compute.images.get
  • GUI上での単一操作で複数のAPIをコールするので、厳密過ぎる権限制御は大変
  • 定義済みのロール
  • Primitive roles
  • 管理者(IAMの管理権限を含む)
  • 編集者(IAMの管理権限を除く)
  • 閲覧者
  • サービス毎の定義済みロール (Predefined roles)
  • 管理者
  • 編集者
  • 閲覧者
  • その他(ストレージ管理者など。定義済みロールの粒度はサービスによって異なる)
  • カスタムで役割を定義することもできる
  • 最小権限が理想ではある
  • 設計によっては運用大変なのでやるなら覚悟を
  • 詳しくはこちら(Understanding Roles
  • Tips
  • プロジェクトをうまく分割すると便利
  • プロジェクトを消すとリソース消せる
  • 開発環境を一括削除できる
  • IAM Condition
  • Private Beta
  • 時刻やソースIPなどを利用してアクセス制御できる
  • 将来的には、デバイスのOSが最新か、などクライアントのコンテキストを評価できるようになるらしい
  • 詳しくはこちら(Overview of Cloud IAM Conditions

データ漏洩を防ぎたい

  • クラウドになって、「境界を守ればよい」って状況ではなくなった
  • マネージドサービスからのデータ漏洩のリスク
  • リスクの例
  • 過剰な権限の付与(例:他のプロジェクトににデータをコピー)
  • クレデンシャルの漏洩
  • 雑な設計や運用によってリスクは増える
  • VPC Service Control
  • 境界線を定義できるサービス
  • 境界線の内外からのアクセスを制限できる
  • 内側から外側
  • 外側から内側
  • ユーザーに権限があってもアクセスを制限できる(VPC Service Controlが優先される)
  • 様々な設計パターン
  • 複数のプロジェクトを1つの境界にまとめることもできる
  • オンプレのネットワークやリソースも境界に含めることができる
  • クライアントのコンテキストに応じた制御も可能
  • 境界をブリッジすることも可能
  • 詳細はこちら(Overview of VPC Service Controls
  • 設計が難しいので、利用するかどうかは慎重に検討を
  • 個人情報などの機密性の高いデータの保護に限定するなど、ピンポイントでの利用はオススメ
  • 仮想マシンの保護は従来通り、BigQueryなどのAPIベースのサービスをVPC Service Controlで制御するなどの使い分け
  • その他の対策
  • DLP(スキャン、匿名化、削除)、PII、保存する前にデータを処理

監査のためのログを管理したい

  • Cloud Audit Logging
  • GCPのアクティビティ、データへのアクセス
  • エクスポートや検索も可能
  • 記録されるログの種類
  • 管理アクティビティ
  • リソースの作成や削除など 課金なし 保持期間400日 長期保存はエクスポート デフォルト有効
  • システムイベントログ
  • GCEで実行されたイベント(Live Migrationの実行履歴も含まれる) 課金なし 保持期間400日 長期保存はエクスポート デフォルト有効
  • データアクセスログ
  • デフォルトオフ(BigQueryを除く)、保持期間30日 サービス毎に有効化できる 課金に注意
  • 詳細はこちら(Cloud Audit Logging
  • GCSやBigQuery, Pub/Subへのエクスポートをサポート
  • ログの集約エクスポートも可能
  • 組織全体・特定フォルダなどの単位でログをエクスポート
  • 詳しくはこちら(Aggregated Exports

DoS/DDoS対策

  • トレンド
  • 数Tbpsクラスの攻撃が発生するようになっている
  • 「YouTubeを50万人同時視聴、HD画質」のレベル
  • 防御手段
  • L3/L4 LB/CDNにおけるDDoS攻撃の緩和
  • Cloud Armor(アプリケーションレイヤーの脆弱性対策 / WAF)
  • リリース前の脆弱性診断
  • Idenity aware Proxy
  • クライアントのコンテキストに基づいて制御
  • GCPのパートナーソリューション

まとめ

  • Googleのサービスで利用しているインフラと同じレベルのセキュリティを得られる
  • 数多くのセキュリティサービスを利用できる

まとめ/感想

普段は触れないサービスや技術に触れるのっていいですよね。新鮮です。 個人的に興味深かったサービス/機能としては、認可の際にクライアントのコンテキストを評価できる点です(現在はLimited Preview)。 ここまでできるようになるとセキュリティリスクはさらに軽減できそうですね。 この辺はChromeやAndroidを作っているGoogleならではって感じですね。 今後もGCPに限らず、幅広くいろんなサービスに触れていきたいと思います。

また、AWSとの違いってどんなところだろうって観点でも聞いていましたが、概要レベルでは大きな差異はなさそうって印象を持ちました。 もちろん、設計思想や抽象化の仕方、そのほか細かい違い(機能の差/特定のワークロードにおける性能差など)はいろいろあると思います。 事業会社のエンジニアの方などはミッションが明確ですので(私からすると)ちょっとした機能/性能の違いを大きな違いとして認識する場合はあると思います。

ちなみに、GCPの公式ドキュメントには以下のような比較ページがあります。

Google Cloud Platform for AWS Professionals

クラウドの検討を実施する際、一番最初に比較表を作ろうとするケースが稀によくありますが、 AWSやGCP「全体」を比較しても有意な差を見つけることは難しいと考えています。 それは、差が少ないということでもありますが、いずれも機能が膨大ですべての比較が困難だからです。 検討にあっては、以下のような順序で考えるべきではないかと考えています。(当たり前だと思いますが)

  • 「自分たちが何をやりたいのか/何を目指すのか」などのビジネス的な目標を明文化
  • ビジネス上の目標を実現するために必要な要件を定義(機能/非機能)
  • 要件を満たしているかを評価するための指標/比較項目を整理
  • 採用するサービスについて、整理した指標を充足しているか調査、比較

最初から比較表を作ることは、上記の段取りを逆からはじめることであり、高い確率で混乱するのではないかと思います。 まずは、やりたいこととそのために必要なことを整理することからはじめるべきだよね、って改めて思いましたまる

現場からは以上です。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.