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

AWS Summit Tokyo 2017

#レポート

#AWS

森永大志

2017.06.01

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

aws-summit-tokyo-2017-longlogo

『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

セッション概要

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

スピーカー：
酒德知明
アマゾンウェブサービスジャパン株式会社
技術統括本部パートナーソリューションアーキテクト

セッション概要：
多くのユーザが、AWS を DevOps プラットフォームとして選択頂いています。スモールスタートは AWS クラウドの良さですが、規模が大きくなるに連れ、開発が複数の AWS アカウントにまたがったり、よりセキュリティ・ガバナンスの強化を求められることがあります。本セッションでは、デベロッパーの皆さんが利用する AWS クラウド環境管理を如何に自動化させ、開発に集中できる環境をデプロイするかについてデモを交えお話させて頂きます。Happy Policy Coding on 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