GCPを古き良き企業で使い始めるためのセキュリティ戦略

Google Cloud Platform その２ Advent Calendar 2018　の9日目です。

TL;DR

• 求めるセキュリティレベルに応じてIDサービスを決めよう
  • GSuite/CloudIdentityが初手
  • 外部サービスも検討しよう（AzureAD,Okta,OneLogin...)
• フォルダ構造を工夫して適切かつ楽なユーザ管理を
  • ユーザ、グループ、プロジェクト、IAMロール等の手間
• 楽さと堅さを兼ね備えたIAM権限管理手法は模索中
  • ポリシー多すぎ問題

はじめに

• お堅い日本企業がGCPに手を出すとこうなる、という経験の共有
  • クラウドとかPoCにしか使えない、という認識の企業
  • 平成も終わるのに、この先大丈夫なのか？という問題意識
• 数ヶ月でまだ道途中
  • なおAWSはもう少し前からやっている、という前提あり

何をしたか

全体像

• （パブリック）クラウドの必要性の説明
  • 既存インフラに対するカウンタを、ハレーションがおきないように説明。。
• GCPであることの説明
  • 今や３大ベンダーくらいしかない
    • 2018Gartnerの記事例
  • ビッグデータや機械学習系サービスの強み
  • 本当はBQとか、強めのサービスが出た時にすぐ会社のお金で試してみたいだけ
• GCP(クラウド)がセキュリティ的に大丈夫であることの説明
  • どう使うと今までやってきた規定や運用に近い使い方が出来るのか
    • クラウドベンダ側のセキュリティは意外とすんなり。ISO27001/27017あたりで説明。
    • その上でユーザがどう作るか、運用するかがフォーカスされる
  • GCPだけどAWSの責任共有モデルでよく説明していた
    • 使いやすい説明系資料が転がっているのはAWSのイメージ
    • 他にもBlackbeltの資料とか
    • IaaSよりもPaaS、FaaS、SaaSとクラウドベンダーに投げ切った方が楽になる、なども
• GCPをセキュリティ的にうまく使える運用の検討、実施
  • ID管理、アクセス制御、権限管理、監査など
  • ここが今回の主題です
• GCPとの契約、財務系の整理
  • 時間かかるけど地道に
  • リセラーの利用で早く安くなることも、ここはメリットデメリット検討余地あり
• GCP使って業務に使えるサービスを作る
  • 幸い、エンジニアとクラウドにあった課題を合わせればサービスはできた
  • クラウドにあった課題、というのがGCPだと大量データ処理か機械学習API使えそうなもの

古き良き企業とセキュリティ

• まずは既存のセキュリティチェックリストを満たすようサービスや運用を考える

  • 統制部署や経営層が話を聞いてくれやすくなる
  • クラウドとはいえ、まずは情報システム、と理解される
  • 既存のルールに100%添い遂げようとすると辛いので、差分が出ても良い
    • AWS、AzureよりもGCPがこの辺差分が大きく出る印象
  • お堅い場合は大本山がクラウド活用推奨している資料をぶつける
    • 総務省、経済産業省、金融庁など。
    • ガイドラインがいくつかあるはず。各企業に合わせたものを。

• チェックリストの要求（一例です）

  • ID管理
    • 企業の管理者がアカウントを発行、削除できるように
  • アクセス制御
    • 限られた拠点や端末からしかアクセスできないこと
    • いわゆるクラウド統制拠点
  • 権限管理
    • 関係あるプロジェクトに最小限の権限を
    • データの社外流出への対応
  • 通信経路の暗号化
    • 平成も終わるのでHTTPとか使わない
  • 監査
    • リスクの高い作業は事前監査が望ましい
      • データ流出、財務リスク（ハイコストのリソース上げ）、。。。
    • 事後監査＋運用になることも。その場合は取りこぼしを出さないケアを
      • 各種トリガー、監査の定常運用化

ID管理

• Gsuiteがおすすめされている
  • そんなサービスが古き良き企業でいきなり認められるわけないだろ！こんな苦労しないわ！
• CloudIdentityになる
  • ドメインがあれば　[e-mail]というGoogleアカウントを自由に作れる
    • GCPアカウントとしてのみ使えるGoogleアカウントを作る
    • 他のGoogleサービスは管理者で利用停止できる
    • FreeEditionならかかる費用はドメイン代くらい
      • GoogleDomainでもなんでも。
  • これでID管理ができた（がベスプラじゃなかったかも。後述）

アクセス制御

• コンソールアクセスやAPIコールできる拠点、端末を縛りたい
  • 家などからアクセスさせない
    • これも古き良き
  • IPアドレスは縛れない模様
  • MFAの認証が特定の拠点でしかできないよう運用するのが全うなきがする
    • ハードトークンを会社で管理、会社のメールアドレスにコードが飛ぶ、など。
  • Googleアカウントの限界
    • おそらくサービス思想の問題。
• GCPのアカウントを別で管理して、ID連携すれば良さそう
  • 権限管理ができて、IP制御、MFAなどができるサービスはある
    • これらをIDaaS（IDentity as a Service)という。Garnter2018MQ
  • Okta,AzureAD,OneLogin,Skuidなど
  • ID系で強い縛りを作りたいならGoogleで完結を目指さない方が良い
  • もちろん自社のADでも良い
    • セキュリティ的にはベストな気はするが関わるチームが増えそうなので、スピード感を求める時には厳しいか

権限管理

• いろんな権限があるので丁寧に勉強しましょう。。

  • 請求先アカウントの管理者
  • 組織（CloudIdentity）の管理者
  • プロジェクトのオーナー

• 管理者、開発者、および監査者にわけて権限設計

  • 管理者はほぼなんでもできるが少数
    • ここら辺は運用がこなれてきたら変えていきたい
  • 開発者は限られたことしかできないが、スケールして良い
  • 監査者は監査ログを見れる
    • 管理者が監査ログを改ざんできないような設定は必要
    • 監査者もクラウド詳しくないので、監査のやり方を教えてあげる必要あり（BQのサンプルクエリ等）

• フォルダ構造を作り、継承でうまくIAMユーザや権限を伝搬させていこう

  • 管理者は最上位でどかっとくっつける
  • 開発者は各チームごとにフォルダ作り、そこにくっつける
    • ユーザ、グループ、ロール、ポリシーのデータモデルを意識する
    • IAM管理ロールや監査系など、つけると破綻するポリシーだけは調べておくこと

通信経路の暗号化

• できる限り、PaaS以上を使えればHTTPS化はGoogleに任せられるはず
  • IaaSでサービス立ててる人らは開発段階からHTTPS化できるようサポートを怠らない
    • エンジニアたちが証明書等をめんどくさいと思ってしまうと、あっさりHTTPでインターネットに開放される
    • セキュリティホール（社内からのツッコミどころともいう）が容易に生まれる
  • サンプルとなるプロジェクトをしっかり作り、それで教育を行う（地道）

監査

• 監査ログは片っ端からとる＋ローテーションしないようにGCS等で保持されるよう注意
• 社内規程上やばい操作についてはStackdriver等でトリガーを作り通知されるようにする

終わりに

AWSやAzureと比べるとやっぱりエンプラ向けの調整は厳しい印象があります。。

苦労話があれば教えてください！