ちょっと話題の記事

[レポート] The Era Of DevSecOps 〜 AWSサービスによるDevOpsとセキュリティのマリアージュ 〜 #AWSSummit

2016.06.04

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

The Era Of DevSecOps 〜 AWSサービスによるDevOpsとセキュリティのマリアージュ 〜

6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016Develoeprs Confrence のセッション「The Era Of DevSecOps 〜 AWSサービスによるDevOpsとセキュリティのマリアージュ 〜」を聴講しました。本記事はそのレポートです。

サービスは迅速にビジネス展開するためDevOpsを実践する企業が増えています。しかし、継続的デリバリーの中でセキュリティをプロセスとして組み込むことが出来なければ、安全なサービスを提供することは困難です。本セッションでは、AWSのサービスによってDevOpsとセキュリティの両立をどのように実現するかを解説します。

スピーカーは 松本 照吾 氏(アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 コンサルタント)、佐藤 聖規 氏(同前)です。

セッション

自己紹介

  • 松本様
    • AWSJのコンサルティング担当。セキュリティがメイン。
  • 佐藤様
    • AWSJのコンサルティング担当。DevOpsがメイン。

本セッションの目的

DevOpsが広まってきました。re:InventでもDevOpsのカテゴリでセッションが展開されています。DevOpsによりビジネスのイノベーション、より早い開発サイクルが可能となりました。ただし、新しいことに挑戦する(イノベーション)ことにセキュリティが障壁となることが多く、AWSJでもユーザー様より相談を受ける機会が多いようです。現在はDevOpsにセキュリティを加えてDevSecOpsという言葉があるくらい主流になってきています。そこで本セッションではAWSにおけるDevSecOpsのアプローチをご紹介いただきました。

アンケート

一行の変更によりデプロイにかかる時間
  • わからない、3ヶ月以上、1ヶ月以上、2週間以上 ⇨ 若干名
  • 1週間以上、1日以上 ⇨ 多い
  • 1時間以内 ⇨ そこそこ

という結果でした。1時間以内が結構いることに驚きました。

ユーザーが期待するデプロイにかかる時間
  • わからない、3ヶ月以上、1ヶ月以上、2週間以上、1週間以上 ⇨ 若干名
  • 1日以上、1時間以内 ⇨ 多い

早いことに越したことはないです。
ただし、早いだけを求めてるわけではなく、ユーザーは安全さも求めています。

  • 再現可能でしょうか?
  • 信頼できるデプロイでしょうか?
  • セキュアでしょうか?

Amazon.comにおけるDevOpsの取り組み

Amazon.comは数千のチームがMicroserviceアーキテクチャによる開発を採用しており、継続的デリバリで複数の環境へデプロイを行っています。その結果、2015年は5,000万回/年のデプロイを行いました。1.5秒/回のペースとなります。

DevOpsとは

あらためてDevOpsを整理します。DevOpsは2つのプロセスのサイクルがあります。

  • デプロイプロセス:BUILD -> TEST -> RELEASE
    • フィードバックを受けて開発し、運用に乗せるプロセス
  • フィードバックプロセス:MONITOR -> PLAN
    • 開発した機能をモニタリング・評価し、次に開発する機能をフィードバックするプロセス

この2つのプロセスをより早いサイクルで回すためには自動化が必要不可欠です。

AWSにおけるDevOpsの取り組み

AWSは以下のサービスをDevOpsに活用することができます。システムの特性に合わせてサービスを選択することができます。

  • AWS CodeCommit
  • AWS CodePipeline
  • AWS CodeDeploy
  • AWS CloudFormation
  • AWS Elastic Beanstalk
  • AWS OpsWorks

DevOps(Innovation) vs Security

  • Agilityの高さからAWSの導入は個別プロジェクトでまずは小さく採用するケースが多い。
    • 欲しい機能がすぐに手に入る
    • 初期費用がかからない
    • プロジェクトに失敗と判断した時にやめられる
  • 個別プロジェクトに成功し、AWSの評価が高く、会社全体でAWSを採用しようとすると、途端にAgilityが悪くなることがある。その要因の一つとして、会社のセキュリティ基準の準拠があげられる
    • 内部統制の壁(新しいことに対する責任の所在)
    • SHADOW IT(クラウドで不透明でアンコントローラブルという認識)
    • セキュリティ人材不足

Cloud Adoption Framework(CAF)

  • AWSが提唱するクラウド採用のフレームワーク
  • セキュリティに関連した記述もある

AWSにおけるDevSecOpsの取り組み

  • Amazon Inspector
  • AWS Config / Config Rules

共通して言えることはプログラマブル、自動化が可能。
これによりAWSのDevOpsのAgilityを落とすことなく、セキュリティを高めることができる。

まずやること

  • Deverloper / Operator / セキュリティ担当者で話し合い、共通認識を持つ
  • みんなビジネスを成功させたいという方向は同じはず

まとめ

  • インフラの透明化
  • セキュリティの効率化
  • ビジネスの安全な加速