re:invent2018に行ってきた(day1)

こんにちは、ひろかずです。
re:invent2018に行ってきたので、参加したセッションの内容をレポートします。

リアルタイム執筆な上に、ヒアリング能力ゼロでやっているので、いろいろ勘弁してください。
内容は、随時更新していきます。

# SEC202-R - [REPEAT] Top Cloud Security Myths - Dispelled!

SEC202

Securitys JOB ZERO
セキュリティという仕事はない
すべてのチームの仕事にセキュリティはついて回る

3つのステージのクラウドセキュリティの関心

## Generalクラウドセキュリティ

物理

- 可用性、アクセスコントロール、機密性

可視化
自動化

- ファイアウォール設定の自動化

自分のコンテンツのcontrol

- オーナーシップ
- アクセス管理
- 追跡性

世界的になcomplianceプログラム

- 第三者認証(PCIDSSとか)
- 継続(AWS Artifactで見れます)
- エンタープライズな合意

AWSで使われてる暗号化

- いたるところに(ハードウェアとかも)
- AWS KMS
- High Standard(FIPS140-2)

セキュリティのテストをどうやるの？

- 共有責任モデル
- 可視性(Amazon Inspectorとか)
- 既にテストされている(マーケットプレイス)


## 特定のサービスのセキュリティ
AWSにおけるパッチマネジメント

- 応答性(自分のタイミングで実施できる)
- スケジュール(定められたメンテナンスウィンドウで)
- その実行基盤は、AWSがマネージします

s3でのセキュリティ実装

- アクセスコントロール(デフォルトでは公開されません)
- 通知(公開されたバケットについて通知できます, バケット設定の変更についても通知できます)
- 応答(好きな公開設定のバケットに放り込めます(SFTPとかで))

AWSクレデンシャルをどう守るの？

- MFA
- STS(一時的なものは盗まれない, IAM Rollでも使ってる)
- GuardDuty(IAMユーザーの誤った使い方も検出できる)

どうやってデータ削除を管理してるの？

- 論理的
- 物理的
- 検証(SOC2レポートに記載されていて、Artifactで見れます)

サーバレスサービスに対する保護はどうやってるの？

- 認証(誰が何にアクセスできるか)
- ブロックのビルド(ビルド環境は分離されています)
- アクセス面の制限(サーバレスの実行環境は分離されてます(共有されておらず、他の利用者はアクセスできない)

## データセキュリティ
AWSが管理する管理者アクセス

- 自動化
- テクノロジーをコントロール(アクセス権限によって、操作できる範囲が分離されている)
- プロセスをコントロール(独立した第三者機関によって検証されている)

AWSのセキュアなハイパーバイザ

- 体験(複雑な構成をシンプルな体験で使えるようにしている)
- カスタムとイノベーション
- 分離されている(メモリ、ネットワーク、ディスクのアクセスが分離されている)

AWSにおけるセキュリティベネフィット
![iOS の画像.jpg](https://qiita-image-store.s3.amazonaws.com/0/46611/ad987faf-2c35-f57d-7f0a-59f3a04d9e5f.jpeg)

セッションでトピックはこちらで解説されているとのことです
https://aws.amazon.com/jp/campaigns/cloud-security/data-safe-cloud-checklist/

## QA
Govクラウドとの違いは？
- パーソナルリージョンなだけで、機能的な違いはそんなにない

# SEC360-R - [REPEAT] AWS Landing Zone Strategies

Landing Zoneで行われるテーマについて、全体感を捉えるようなセッションのようです。

## マルチアカウントアプローチ
コンテキストとして、用途別にAWSアカウントを分けるというアプローチのようです。
今までは用途毎にVPCを分けてしまうというアプローチがあったと思いますが、AWSアカウントとして分けてしまうという考え方のようですね。
主な用途は以下になります。

- Orgs: アカウントマネジメント

コアアカウント

- Log Archive: Securityログ
- Security: Securityツール、Config ruleとか
- 共有サービス: ディレクトリや制限の観察
- ネットワーク: dx

開発者アカウント

- Dev Sandbox: エンターブライズ、学習

チーム/グループアカウント

- Dev: 開発環境
- Pre-Prod: ステージング環境
- Prod: プロダクション環境
- Team SS: Team Shaerd Services, データレイク

![2018-11-26 13-18 Office Lens.jpeg](https://qiita-image-store.s3.amazonaws.com/0/46611/244c8285-1f30-f2f1-c2fd-eecf42ebbabe.jpeg)

以降に、各テーマ別に使う要素やキーワードを列挙します

## ログ保存アカウント

- s3バージョニング(MFA Deleteも)
- CloudTrail Logs
- Securityログ
- 一つのSourceが真実
- ユーザーログインをアラートにする
- 制限されたアクセス

## 共有サービスアカウント

- データセンターとの接続
- DNS
- LDAP
- 共有サービス用VPC
- デプロイツール(ゴールデンAMI、パイプライン)
- インフラのスキャン(動作していないインスタンス,不適切なtag,スナップショットライフサイクル)
- モニタリング
- 制限アクセス

## チーム共有サービス

- 組織の成長
- チームで共有
- プロダクト特化の一般サービス
- データレイク
- 一般的なツール
- 一般的なサービス

例えば、データベースチームが使うサービス基盤では、そのAWSアカウントに扱うデータを蓄えて、DBAが使うツールを用意しておく環境という文脈のようです。

## QA
会社によってフィットする使い方が違うと思う。
サービスが多すぎて、何を使ったら良いかわからない。

- それぞれ話を聞くので、解決していきましょう。

## 感想的な何か
この考え方のキモは以下だと思います。

- IAM権限をアカウントごと分離してしまう
- Organizationは、役割別のAWSアカウント毎で許可する権限をコントロールでき、その枠の中で権限を管理してもらう
- DBAチームですら、本番データには触らせないようにし、扱うデータをコントロールすることでデータ流出リスクもコントロールできる
- Private Link(Servicer Endpoint)やPeeringを使って、サブシステム間のネットワーク結合度を必要に応じてコントロールできる

スライドを思い切りふっとばしてのセッションだったので、スライドの公開が待たれますね！

# ADT401 - Real-Time Web Analytics with Amazon Kinesis Data Analytics

ログをAmazon Kinesis Data Analyticsでリアルタイムに処理するシステムを作るワークショップです。
4xx系なのでエキスパート向けのセッションですが、Gitの手順を基にCFnで環境を構築するので、淀みなくできました。

クリティカルなログは、発生前と発生時、発生直後に記録される。
トラディショナルなバッチシステムは、発生後からログ置き場に移動されてからログを評価する。

今日はCloudFormationでこんな構成を作るそうです。
<img width="899" alt="スクリーンショット 2018-11-26 21.49.31.png" src="https://qiita-image-store.s3.amazonaws.com/0/46611/20a43ca4-6ee4-66a7-0cfa-72e0eb151e12.png">

ワークショップの手順は[これ](http://bit.ly/2CLtFYY)です。
みなさんも追体験できますよ！（課金は自分持ちです！）
まず、EU(アイルランド)でCloud9を立てろとのことです。

- Cloud9を使う時はChromeかFirefoxを利用することをおすすめします。

基本的にCloudFormationのスタックを回しながら進めるのですが、途中でデータ生成しながらスタックを更新させていくとか、かなりよく練られたシナリオでした。
ワークショップをやる時は、是非参考にしたいですね。

今日はここまでです。
お疲れ様でした！