【レポート】「AWSコンサル事例でわかるパーソルが実現した、ガバナンスとスピードを兼ね備えた次世代型AWS共通基盤とは」AWS Summit Tokyo 2019 #AWSSummit

AWS Summit Tokyo 2019のセッションレポートです。こちらでは「AWSコンサル事例でわかるパーソルが実現した、ガバナンスとスピードを兼ね備えた次世代型AWS共通基盤とは」の内容をレポートします。

AWS Summit Tokyo 2019

#AWS

#イベントレポート

#セキュリティ

臼田佳祐

2019.06.13

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

こんにちは、臼田です。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

本ブログでは『AWSコンサル事例でわかるパーソルが実現した、ガバナンスとスピードを兼ね備えた次世代型AWS共通基盤とは』に関する内容をレポートしたいと思います。

AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

パーソルホールディングス株式会社グループIT本部インフラ部　コアインフラ室担当

増田健吾

アマゾンウェブサービスジャパン株式会社プロフェッショナルサービス本部コンサルタント

福井大樹

現在、パーソルグループではオンプレからクラウドへのシステム移行を促進し、2023年にはクラウド活用90%を目指しています。しかし、ガバナンスを向上したいグループIT部門と自由度やスピードを高めたい事業部門との間で葛藤が年々大きくなり、現状の共通基盤では双方の要求を実現することが困難となる課題を抱えていました。本セッションでは、パーソルグループがマルチアカウント化による権限移譲と “ガードレール”型セキュリティモデルによって、ガバナンスとスピードを共存させた次世代型グループ共通基盤を実現した事例を紹介します。

レポート

セッションの概要
- 多様化するニーズへの対応とガバナンスを両立するための考え方
- 実際の事例
- 情報システムの管理や運用をしている方向け

AWSから共通基盤の話

なぜ共通基盤が必要なのか？
- 多くのお客様がクラウド導入で歩む4つのステージ
  - プロジェクトフェーズ
    - 限られたメンバーがクラウドを操作する
    - 効果的な選択肢か検証する
  - foundaton
    - CCoEが立ち上がる
    - ガイドラインや基盤が整備
    - データセンターと接続
  - マイグレーション
    - 長期利用の準備
    - データセンターの縮小
  - reinvation
    - デフォルトの選択肢になる
    - クラウドに最適化していく
- Foundationフェーズでは基礎づくりに取り組む
  - 共通基盤の構築が行われる
- 共通基盤は多様な目的を持つ
  - クラウド利用者の負担軽減
  - マイグレーションの加速
  - ガバナンス
    - 統一された認証など
  - セキュリティ
  - コスト管理/最適化
    - 請求を共通基盤にまとめてボリュームディスカウントも
  - シャドウクラウドの抑制
共通基盤はクラウド活用のプラットフォーム
- 共通基盤の提供は一般的にIT部門
- セキュリティや財務とも連携する
- クラウド共通基盤に乗る役割
  - ベースラインアーキテクチャとセキュリティ
  - コストと請求
  - 共通構築/運用サービス
- ビジネスレイヤーではその上に成り立つ
共通基盤が直面する課題
- 共通基盤へのニーズはフェーズが進むと多様化する
  - マイグレーションが進んでreInvationが近づくとより増える
  - マイグレーション
    - 社内マジョリティ層の以降
    - データセンターに近いニーズ
    - 量が増える
  - クラウド最適化
    - 先進的なクラウド活用
    - 広いマネージドサービスの活用
    - 種類が増える
- クラウド運用初期に見られる中央集権的な共通基盤
  - シングルアカウント
    - 管理部門や全ての事業部門で1つのアカウントを共有
  - オンプレミス仮想化基盤の運用を投手
  - 利用部門へのAWSマネジメントコンソールの制限
  - 限られたAWSサービス利用
- ニーズが多様化してくると難しくなる
  - マイグレーションではスケーラビリティの限界を迎える
    - シングルアカウントで管理できない
    - 管理組織の運用負荷が増大
  - クラウド最適化では構築/変更のリードタイムが増える
    - 開発速度、市場投入速度がでない
  - AWSサービスから得られる価値の限界
    - クラウドをフル活用できない
多様化するニーズへのアプローチ
- ゴールはニーズへの対応とガバナンスの両立
- キーワードはブロッカーからガードレールへ
  - ブロッカーではなにかあるたびに確認するためスケールしない
  - ガードレールではやってはいけないところをしっかり整備
    - セキュリティグループの設定チェックを自動化したりして、管理者がすぐに気づけるようにする
- 共通基盤の主要コンセプト
  - 戦略的なマルチアカウント構成
    - 管理用アカウントと利用者用アカウント
    - 利用者/サービス単位のアカウント払い出し
  - 自動化されたセキュリティガードレール
    - セキュリティポリシー違反を検知防止するためのガードレールを自動的に展開
      - CloudFormation StackSets等
  - 利用者への権限委譲
    - 利用者はガードレールの中で自由にAWSを活用
  - 監査ログの集約
    - セキュリティチームによる監査を容易化
- ベースラインと共有サービスで異なるニーズに対応する
  - プラットフォームベースラインを容易
  - 自由にやりたい利用者にはセルフで開発してもらう
  - 支援してほしい利用者には共通サービスを使えるように提供する
    - テンプレート
    - 構築サービス
    - 監視・バックアップ
  - 継続的な改善が成功の鍵
    - ニーズに合わせて共通環境を改善していく
    - 新しいサービスにも対応していく
AWS Landing ZoneソリューションとAWS Control Tower
- AWS Landing Zoneソリューション
  - AWSマルチアカウント環境のセットアップを自動化する
  - 容易に導入可能なソリューション
  - AWSのプロフェッショナルサービスやSAでの対応が必要
- AWS Control Tower
  - マルチアカウント環境のセットアップと統制のための最も容易な方法
  - まだリリース前
- これらを活用していくと容易に環境を整備できる

パーソルにおける次世代共通基盤への取り組み

パーソルとクラウド
- クラウドジャーニー
  - 2014年から検討開始
  - 中央集権型と権限委譲型の共通基盤を構築
  - 2023年までにクラウド利用率90%を目標にしている
  - そのために次世代共通基盤を作っている
課題
- これまでの2種類の共通基盤
  - 中央集権型
    - ガバナンス重視
    - AWS管理チームで実施
    - セキュリティと運用をAWS管理チーム責任
    - 1角AWSアカウント内でVPCによって分離
    - 利用者の課題
      - リードタイムの発生
      - 自由度の不足
    - 管理者の課題
      - 運用の負担
  - 権限委譲型
    - 自由度とスピード重視
    - 利用者毎アカウント払い出し
    - 利用者の課題
      - セキュリティの負担
    - 管理者の課題
      - 監査の負担
次世代共通基盤について
- プロジェクト体制
  - AWS管理チームでプロジェクトマネジメント
    - 設計構築チーム
  - グループIT、セキュリティ部門、事業会社、AWSプロフェッショナルサービスと連携
- コンセプト
  - ガバナンスの向上と統一
  - セルフサービス化によるスピードアップ
  - 多様なAWSサービスを利用可能
  - クラウドの価値を最大限に引き出してビジネスを促進する
- 全体像
  - アカウント構造とネットワーク
    - AWS Organizationsマスターアカウント
      - 請求など
    - ログ集約アカウント
      - S3にログを集約
    - セキュリティアカウント
      - GuardDuty集約
      - 監査用IAM Role
    - 共有サービスアカウント
      - 踏み台など
    - 利用者アカウントは本番と開発、ステージング等で分ける
    - 共有のDirect ConnectやTransitGatewayを活用
- 具体策
  - セキュリティガードレール
    - 主要な検討ポイント
      - 設定するガードレールは何を基準にするか
        
        共通基盤として予防・検知すべきアクティビティや状態は何か
        
        拠り所は自社のセキュリティガイドやチェックリストであるべき
        
        既存のクラウドセキュリティチェックリストを活用
        
        例
        
        ストレージサービスのインターネットアクセス許可をしないという内容にはAWS Configルールで検知するガードレール
        
        IDS/IPSの設置はGuardDutyの無効化を検知するガードレール
      - どう展開するか
        
        AWS Landing Zoneソリューションをベースに活用してガードレール展開を自動化
        
        Organizations SCPを活用
  - 利用者への権限委譲
    - 主要な検討ポイント
      - 権限を移乗してセルフサービスを可能にしたい
      - IAM Roleの作成も異常したい
      - VPCなど一部禁止したい
      - 課題: IAM Roleの作成権限をどうやって適切に移譲するか
    - IAM Boundaryを活用して適切な権限委譲を実現
      - 利用者自身による権限昇格の防止
      - 利用者が作成するIAM Roleの最大権限範囲を指定
- 次世代共通基盤の効果
  - ガバナンスの向上と統一80%
  - セルフサービス化90%
  - AWSサービス数は20->40に増えた
    - 100にしていきたい
これからどうしていくといいか
- 管理者ではなくサービス提供者
  - 基盤管理者だとシステムが中心
    - 共通基盤の管理と運用のみ
    - リアクティブになる
  - サービス提供者となって利用者を中心とする
    - プロアクティブな支援や技術支援が可能
    - 継続的な改善を行ってクラウドの活用を加速させることができる