AWS Summit Tokyo 2017 DevSecOps on AWS – Policy in Code – 2017/06/01

AWS Summit Tokyo 2017に参加してきました。
特に印象に残ったセッションについてまとめておこうと思います。

初めに参考になるリンクを貼っておきます。

トレンドマイクロの南原さんに聞いたセキュリティ対策の自動化
Deep Security＋AWSで実現する「DevSecOps」ってなに？
http://ascii.jp/elem/000/001/227/1227023/

セッションの概要

スピーカー

酒德 知明
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 パートナーソリューションアーキテクト
https://aws.amazon.com/jp/careers/newgraduate-employee/sa1/

概要

AWSはすでにDevOps型開発をしていく上でのプラットフォームとして多くの企業で採用されています。
AWSのクラウドの良さは小さな規模からスタートアップをすることができる点ですが、規模が大きくなるに連れて、開発が複数のAWSアカウントにまたがったり、よりセキュリティ・ガバナンスの強化を求められることがあります。
このセッションでは、Developerが利用するAWSクラウド環境構築を自動化させ、開発に集中することができる環境をデプロイする方法についてデモを交えて紹介します。

セッション詳細

• 対象
  • DevOpsを既に実践している人
  • DevOpsをこれからやろうとしている人
  • 既にAWSを使用して開発を行なっている人
• DevOps + Securityとは一体何を指しているのか？
  • 実践方法についてご紹介します

DevSecOps

まずはじめに会場全体の参加者に対してQuestion「DevSecOpsというキーワードを聞いたことがある人は？」
１割〜２割程度、まだまだ日本国内では浸透していない印象を受けました。

本日はAWSのサービスを１つ１つご紹介するのではなく、複数のAWSのサービスを組み合わせてDevSecOpsを実現する方法をご紹介します。

そもそもDevOpsとはDeveloperがUserに対してどのようにサービスを提供するか、またUserがDeveloperにどのようにフィードバックをし、そのサイクルを回していくのかという仕組みを作ること。
ではDevSecOpsとは？？　→　そのサイクルの各工程でSecurityの概念を導入すること。

DevOpsを回す開発者はSecurityを後付けで担保しにかかりがちであり、従来はSecurityについてPDCAを回すことが非常に困難だった。
それではそもそもSecurityを考慮に入れたDevSecOpsで開発サイクルを回すのが良いのではないでしょうか？

Secutity Automation

AWSサービスを使って、DevOpsサイクルにSecurityを如何に組み込むか、
ここではその方法として３つの方法をご紹介します。

Secutity Control

• AWSではIAMを使って権限管理をすることができる。
• AWSではRoleの考え方と、一時認証が重要
  • 1つのユーザに対し、N個のRoleを割り当てることができる。
  • ユーザAはRoleを切り替えるだけで別の権限を使用することができる。
    • 例えば、通常はDev環境しか触ることができないユーザ
    • 本番作業時だけ、PrdRoleを使用して本番環境に触れるようにする。
  • Roleはユーザに一時権限を付与する。一時権限用のKeyは一定の時間が立つと向こうになるため、セキュアである。
• Tagを使用すると、一部のリソースにだけアクセス権限を付与することができる。

以上がSecurity ControlをAWSで実現させるための方法。至極一般的な権限管理なのではないでしょうか。
しかしながら開発者に権限がないために新しいことをしようとしたときにRoleが付与されていないために何もできません状態になってしまうのは嫌ですよね。。。
そこで、次にご紹介するProactive Monitoringの考え方をご紹介しましょう。

Proactive Monitoring

• 開発者が操作したイベントを監視して、それに応じてアクションを起こす。
• AWSでは様々なサービスを用意しています。
  • CloudTrail
    • これはAPIの実行を記録します。
  • CloudWatch Event
    • これはAPIのイベントなどを検知してアクションを起こします。
  • Config
    • 定常的に設定値などを記録します。
• 例をご紹介しましょう。CloudTrailを無効化された際に、その操作をした開発者に対してどのようなアクションを起こすのか
  • まず、無効化するAPI呼び出しをCloudTrailで記録しておきます。
  • そのつぎに、そのAPIイベントをトリガーにしてCloudWatch EventsLambdaを呼び出します。
  • Lambdaでは次の処理を実行させます。
    • まず、CloudTrailを再度有効化します。（開発者に勝手に落とされても大丈夫、Lambdaが再起動する）
    • １度CloudTrailを無効化した開発者に対しては何も行いません。（操作を誤ってしまったということを想定して）
    • 複数回CloudTrailを無効化した開発者に対しては権限を剥奪します。（悪意のある攻撃者として認識）
    • 一連の行動、ログはDynamoDBに記録しておきます。

以上のようにProactive Monitoringという方法をとることがAWSではできます。従来のSecurity Controlの方法のように最小限の権限を与えるのではなく、権限をたくさん与えておいて徐々に減らしていくというほうが、スピードを求められるDevOps的開発サイクルには合っている。

Multi Region / Multi Account

• 複数のリージョン・複数のアカウントで同じ管理を行いたい場合はどうすればいいのでしょうか
• まず、Adminのアカウントにのみユーザを作成します。
  • 他のアカウントにはRoleのみを付与します。
• Proactive Monitoringの設定はCloudFormationで作っておいてコピーできるようにしておく。
• Adminのアカウントの設定管理までのCloudFormationで作った方が管理しやすくなります。

感想

従来の考え方のような権限を付与するSecrutiyControlではなく、権限をたくさん与えていて徐々に減らしていくというProactive Monitoringのような方法がDevOpsのシナリオには合っているし、開発者サイドの人間がSecurityに関わる体制は良いなと感じました。Developer、Operator, SecurityManagerがそれぞれの垣根、責任範囲を超えて進めることのできる体制「DevSecOps」、いいですね。