AWS summit tokyo 2018 今日は２日目です。

各公演を聴きながらメモった内容です。

そのうち公式に動画やプレゼン資料がアップロードされるはずなので、そちらも是非！

[10:00-10:40] CodeStar で実践する GitHub Flow ープルリクベースでサーバレスアプリを自動デプロイ！

• githubは現在2700万アカウント
  
• 東京にもオフィスがあるよ

Security Alert

• コードの脆弱性を検知してメールなどで修正を促すもの

Code Owner

• StaticはWDで、PHPはPGで、とかとかコード毎にオーナーを決めて対象のディレクトリにPRが来た場合にレビューを強制するなどができる

Project Board

• 進捗状況の可視化など
  

Issueテンプレート

• テンプレートを複数準備できる
• あらかじめ埋めて欲しい内容が埋まった状態でissueをかける

去年AWSのCodeStarと連携を開始

CodeStarって

• AWSのツールなどと連携して閑居構築を簡単にできたり
• ツールチェーンになってる

連携すると

• githubとCodeStarを連携すると、あとは自動で土台ができてる
  
• repositoryも勝手に作られてて、サンプルコードがあって、それでサーバレスアプリが立ち上がる
  
• あとはこのrepositoryを修正していけばOK
  
• さくっとアプリを作りたいときはすごく便利
  
• IAM作ってそいつでCodeStarとgithubを連携するだけ
  
• githubのmasterにマージしたら勝手にビルドが走ってビルドまでやってくれる
  
• CI/CDの拡張も可能（自動テストとか）

ATOMのgithub拡張がよさげ

eclipseのgithub拡張に似てる

[11:00-11:40] AWS 上の Blockchain アプリケーション実装

AWSとBlockChain

AWSのスタンス：BlockChainに関するマネージドサービスはない。特定の業界のサービスはやらないよ。ユースケースやワークロードを限定しない。

事例：

• Bank of England
  
• coinbase
• ConsenSys 
• Kaleiod

AWS Blockchain パートナーズポータル

AWS Blockchain テンプレート

• 一般的なblockchainフレームワークを素早く作成するもの
• AWS CloudFormationテンプレート

Daaps開発にAWSを活かす

セキュリティを意識した開発シナリオ

※Geth - go ethereum

※tluff

イーサリアムならConsenSysがベストプラクティスだしてる

以下のようなプロセスをCodePipelineで制御する

1. ローカルで開発、テスト
1. AWS CodeCommit
2. Cloud9でもできなくはない
2. CIがキックされてテストが動く
1. AWS CodeBuild
3. privatenetにデプロイ
1. privatenet on AWSにデプロイするステージを追加する
4. 承認プロセス　←  手動でさせたい
1. 承認というアクションがあるので追加する
2. pipelineにボタンが出てくるのでIAMで権限を付与することで手動承認を実現できる

セキュリティの強化ポイント

自動テスト、デプロイフローの徹底

[12:00-12:40] AWS のオペレーション最適化の勘所

• Well-Architected Framework
  
• Operation as codeの実装：自動化でヒューマンエラーを減らす
• Annotated Documentation：ドキュメントも自動で更新しよう
• 頻繁に小さく可逆な変更を加えられるワークロードのデザインを
• GameDayを実施する
• 障害予測する
• イベントと障害対応から学ぶ：ログ分析と可視化
• AWS Configでタグを適切に活用しているかチェックできる
  
• system managerを使えるようになる
• タグの使いすぎ頑張りすぎに注意
• タグの設計指針：AWS Tagging Strategy参考
• メンテナンスの通知を適切に受けとる
• AWS Personal Health Dashboard、AWS Health APIを利用する
• 複数のアカウントをまとめて管理
• AWS Organization：請求も割引もひとかたまりでできる
• サポートを活用
• アカウントを分けて複数運用しているときは、問い合わせようとしているリソースの所有権を持っているか確認すること
• Trusted Advisor
• サービスを横断的に監視

[13:00-13:40] ［ソフトバンク株式会社］ クラウド設定はまずは見える化！クラウドセキュリティの新常識とは？

SoftBank vision fund - 世界最大規模のFund

大きいFund   ＝　AWS

• クラウドセキュリティの責任の分界点を理解する必要がある
  
• ハードウェアはAWSだがコードは顧客にある
• セキュリティグループを適切に設定すること
• クラウドのコントロールレベルで操作できるAPIを操作する
• マイクロサービスは責任を囲い込みセキュリティもIAMやSGなどで各サービスに最小の設定をいれることができる　→  複雑化してしまう
• DevOpsはセキュリティを確保した上でスピードが求められる
• セキュリティとコンプライアンスをセットで継続的に更新する
• 情報漏洩
• これはほぼ設定ミスが原因なので未然に検知して予防できたはず
• S3のバケットの設定とか
• クラウドにマッチしたクラウドセキュリティ製品が必要
• 自動化されたセキュリティソフトそして継続的に運用する
• サービス全体の設定などをチェックするもの
• Activeな防御

SaaSプラットフォーム：Dome9 Security

• Network Security Module
• 可視化機能：SGの可視化
• １ページでリソースを見渡せる
• AWSのBestPlacticeを組み込んでるのでそれに沿ったレポートの作成もすぐにできる
• IAM Safety

[14:00-14:40] AWS によるセキュリティ・オートメーションの実践

1.  クラウド時代でのオートメーション

スプレットシート　→ プリシー文書　→チェックリスト・・・労力。

自動化したいね

でももっとオートメーションが不可欠な理由

1. 拡張性
• オンプレだと、リソースが必要だと調達して、その後にセキュリティ対策をしてた。ITとセキュリティが分離してる。
• クラウドはリソースがどんどん増やせる：セキュリティの自動追従が求められる
• ITとセットで考える
2. コスト
• 労力・時間の削減
• クラウド時代は、今わからない将来のサーバ数に対してのセキュリティ対策が必要
• しかも半期に一回じゃなく、毎分で増えるかもしれない　→  スプレットシートで管理なんてやってられない
3. 信頼性
• 品質の担保→人為的ミスをなくす
• データ処理は機械にやらせて、そのツールを作ることを人間がやる

2.  セキュリティ・オートメーションのパターン

自動化の最小パターン：入力(trigger)　→   評価(check)　→  実行(action)

セキュリティにおいて自動化したいこと

• 攻撃、障害、脆弱性、構成の変更をトリガーに
• メトリクス、KPIをトリガーに
• 定期的にログ分析したりとか

実現するためのサービス

• 何かのサービスをhookに、Lambda Functionが評価する、そして何かのサービスに流す
• セキュリティのインシデントはタイミングや規模がわからないけどやりたい処理はわかってるのでサーバレスのFaaSがあってる

3.  セキュリティ対策のユースケース

リスクベースのアプローチで考える起点

• 脅威：外部から
• AWS WAF：いわゆるfirewall
• AWS Firewall Manager：WAFのルールを一元管理
  
• CloudWatch Eventsから定期実行→Lambda→WAFの設定を変更
• GuardDuty：ポートスキャンを検知
• 脆弱性：内在する数
• AWS Config：リソースの設定変更の継続的記録
• AWS Config Rules：企業ポリシー準拠の継続的監査と評価
• 許可されてないOSSの検知
• Amazon Inspector：脆弱性診断
• 情報資産：価値が高いほどインパクトが大きい
• Amazon Macie：機密情報の監視

これらは起点であり、これをトリガーにしてLambda Functionに渡す

このスライドの１４ページも参考に。

EOL