【レポート】AWS Summit Tokyo 2017: DevSecOps on AWS – Policy in Code – #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは『DevSecOps on AWS - Policy in Code』をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

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

セッションレポート

以下、セッションのレポートです。

• 対象
  • DevOpsを既にやっている人
  • DevOpsをこれからやろうとしている人
  • AWSを既にやっている人向け（基本的な説明はしない）
• DevOps＋Securityについて考えましょう
• 一つのシステムでも複数のシステム効率的にセキュリティを導入する

DevSecOps

• 聞いたことある人は？
  • 1割ほど
• 単体のAWSサービスの話ではなく、複数のAWSサービスを組み合わせてDevSecOpsを実現する方法をご紹介
• DevOpsは開発者が顧客にどうデリバリするか、顧客がどう開発者にフィードバックするかサイクルを作ること
• DevSecOpsはその各工程でSecurityの概念を導入する
• じゃあ、DevOpsではなく最初からDevSecOpsで導入したほうが良くない？
  • 今まではSecurityについてPDCAを回すことが非常に困難だった
  • ルール改定が困難なのでSecがDevOpsの邪魔になる

Security Automation

Security Control

• いわゆる権限管理
• AWSではIAMで管理できる
• AWSではRoleと一時的認証が非常に重要
  • 1ユーザにn個のRoleを割り当てる
  • ユーザAはロールを切り替えるだけで別の権限を使用できる
    • 例えば、通常はDev環境しか触れないユーザ
    • 本番作業時だけPrd Roleを使用して本番環境に触れるように
  • Roleはユーザに一時的権限を付与する
  • キーは一定期間経つと無効になるため非常にセキュア
  • ユーザのアクセスキーはなるべく使わないようにする
• Tagで一部リソースにだけアクセス権限を与えることが出来る
• 既にアクセスキー発行しちゃっている場合は？
  • git-secretsというツールが提供されている
  • アクセスキーが書かれているソースのコミット防止
  • 既存レポジトリのスキャン
• Security Controlは簡単なんだけど、開発者に権限が無くて新しいことが出来ないということはしたくない。。。

Proactive Monitoring

• イベントを監視してそれに応じてアクションを起こす
• 色々なサービスがある
  • CloudTrail
    • APIの実行を記録
  • CloudWatch Event
    • APIイベントなどを検知してアクションを起こす
  • Config
    • 定常的に設定値などを記録
• 例）CloudTrailを無効化された際に自動的に対処
  • 無効化するAPI呼び出しをCloudTrailで記録
  • そのAPIイベントをトリガにCloudWatch EventsでLambda呼び出し
  • Lambdaで以下を実施
    • 真っ先にCloudTrailを再度有効化
    • 複数回無効化したユーザに権限を剥奪するポリシー付与
      • 攻撃者と判断して権限を剥奪する
    • 情報をDynamoDBに記録
• AWSの権限付与は最小限を与えるのではなく、権限をたくさん与えて減らしていくほうがあっているし、それが出来る

Multi Region/Multi Account

• 複数のリージョンや複数のアカウントで同じ管理を行いたい場合どうする
• Adminのアカウントにのみユーザを作成
  • 他のアカウントにはRoleのみ作成する（ユーザは作らない）
• Proactive Monitoringの設定はCloudFormationで作り複製できるように
• Adminのアカウントの設定管理もCloudFormationで作ったほうが管理しやすい
• デプロイの仕方
  • AdminでCloudFormationのテンプレート作成しS3に保管
  • StepFunctionで各アカウントにテンプレート適用（StepFunctionにRole権限を与える）
    • StepFunctionを使えば並列に実施可能

まとめ

• 最初の段階でSecurity Automationを作っておけば後が楽
• Devの人間がSecurityにも関わることでより良いものになる

• 紹介したツール

  • git-secrets：https://github.com/awslabs/git-secrets
  • Security Automation：https://github.com/awslabs/aws-security-automation

感想

Devでアプリのテストを書くように、AWSではSecurityについてもコードのように記述することが出来ます。
SecurityのベースラインをCloudFormationで記述しておいてStepFunctionで複数アカウント、リージョンに適用するという形は非常に面白いなと思いました。