こんにちは、ひろかずです。
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におけるセキュリティベネフィット

セッションでトピックはこちらで解説されているとのことです
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, データレイク

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

ログ保存アカウント

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でこんな構成を作るそうです。

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

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

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

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

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