こんにちは、ひろかずです。
Security Engineering Casual Talks #1へ行ってきたので、レポートします。

第一回！
クラウドサービスのセキュリティ機能を使ったセキュリティ機能の実用例などを取り扱っていくそうです。
Casual Talksとは、ビールを飲みながら気軽に話す勉強会のことだそうです。

会場はcookpadさん
シャレオツスペースに集まって、プシュッとやってから開始です！

例によって、リアルタイムで書いているので、誤字脱字表記ゆれはご容赦ください。

おしながき

自由でセキュアな環境のつくりかた

@kani_b (Cookpad)

踏み台環境のあれそれ

@ken5scal (FOLIO)

開発現場で使えるAWS KMS

okzk (CyberAgent)

自由でセキュアな環境のつくりかた

@kani_b (Cookpad)

主戦場はAWSとのこと
最近は機械学習やログの話を発信しているとのこと
cookpadサービスは、世界展開してるんですって！広がるレシピワールド！

新しい取り組み

cookpadtvで乃木坂のメンバーが作る料理動画を発信
Amazon Echo Spot向けのスキルを提供
IoTスマートキッチンを立ち上げる際のレシピプラットフォーム

クックパッドとクラウド

2011年にDCからフルクラウド
多くのサービスがAWS
一部Firebase

背景

機能事業などの新しい取り組みを加速したい

当時の組織構造

インフラ部を機能横断的に各サービスの基盤を担う
セキュリティ対策もインフラ部が担っていた
社内の情報管理もインフラ部がやってた

中央管理の限界

インフラ部のさばける総量が、スケール/スピードの限界
レビュに時間がかかって、ボトルネックになった
AWSの良さは、すぐに自分で試せること。その良さを殺しているのではないか？

開発者用アカウント

開発者なら誰でも自由に使えるAWSのアカウントを作った
本番とは完全に分離
IAM空間も分割
SAMLログイン

権限管理

必要なサービスのAdmin
特定のサービスのみを許可しないポリシー
Allowから、NotActionで引き算するルール

ログの記録

CloudTrail, FlowLogs
本番アカウントのs3バケットに保存して、ログの変更や削除をできなくする

ログの分析

Graylogで分析してる
詳しくは

AWS Config

変更差分の記録

使い方

Outputの先を本番アカウントに設定する

Config Rules

設定変更をトリガして、Lambdaで設定をチェックできる
SGとかチェックする
awslabs/aws-config-rulesとか便利リポジトリから入手できる

GuardDuty

普段使われないIPからのAPIコール
インスタンスの通信先が普段と違う

使い方

アラートはGitー＞PDで通知してる

ネットワーク構成

踏み台SSHサーバがあるVPCからPeering経由で接続できるようにする
踏み台を集約して、TOTPやFIDO U2Fに対応させる
Nameタグを使った正引き逆引き(インスタンスを起動すると、アップデータが拾ってDNSに登録する)

開発者アカウントの特徴

防ぐより、検出できるということ
アカウントに求められる柔軟性から考えた
AWSサービスを素朴に使った構成なので再現しやすい

実運用

意外とアラートは多くない
利用量は多い
インスタンスを起動して気軽に実験(新サービスの検証)

踏み台で環境にTeleportする

@ken5scal (FOLIO)

SREFチームでコミットした踏み台環境

Bastion

アクセス制御がなされた環境
職権の分離
監査

Teleport

OSS, CNSF
ブラウザベースの踏み台
リモートの人とセッション共有
SSHからの開放？（されない）
Githubにソース上がってて、問題はissueになげられる
インスタンスのタグを拾って、権限割当ができる(サクッとはできない)
リプレイも見れる
Enterprise版ならs3に記録を保管できる
秘密鍵管理からは開放される
EnterpriseならIdP使える(SAML,OIDC)
誰がログインできるかを制御できるのが最高
署名付きの期限付きの鍵を落として使っているので、OpenSSH自体はそのまま使える
demo
構成:NLBを使ったマルチProxy,マルチAuth
Proxyにakamai wafをかける
緊急踏み台は用意しているけど、そこはKryptoniteを使ってる
Terraformで展開している

Deployment

Terraformで展開しているが、サービスが増えるごとに構成セットが増えていっている
CodeDeployを使ってもう少し楽にしたいなぁ
Trusted Cluster組みたいなぁ
RBACの最小権限をロール定義やりきるのは大変だなぁ
中央集権的にできていないので、それぞれ定義しないといけない
RBACからABACにそろそろやる必要があるんじゃないか？
中央Controlプレーンを作ることになるんじゃないか？
Okta

Logs

Dynamoのログを見るのは辛いのでDDに投げるのがいいよね
SCP使えばダウンロードできちゃうじゃん
ワカモレやWindows VDIを使えるようにするのかな

社内イベントやるよ！

Scramble!

QA
ローカルユーザーは要る？

権限をControlするなら必要

SSH鍵の管理はしやすくなってる？

なってる。IdPがある。

幕間

ご飯出ました！
美味しかった...

開発現場で使えるAWS KMS

okzk (CyberAgent)

課題1

センシティブな情報は暗号するってのはわかる。
どうすりゃ？安全に暗号化/復号できるの？

KMS
Keyはエクスポートできない
APIで暗号化/復号できる
CloudTrailでログが取れる

KMSの制限

暗号化対象は4KBまで
暗号化/復号は、秒間1000リクエストまで

KMS Envelop Encription

実際に暗号化/復号に使うデータキーをKMSで暗号化しておく方式
この方式なら、スロットリングに引っかからない

課題2

暗号化したデータをどこに永続化すればいいの？

ParameterStore/SecretsManger
暗号化したデータの保存のためのストレージサービス
KMSと統合されている
ParameterStoreは、階層型ストーレージなので、まとめて情報を取ることも可能
どっちを使っても、対して変わらんが、SecretManagerは有料
SecretManager定期更新を行うLambdaもサクッと作ることができる。

課題3

アプリ側はどうしたい？

環境変数に格納してほしい
env-injector
ParameterStore/SecretsMangerからクレデンシャル情報を環境してから、アプリをexecする
Githubに公開されている
Dockerでも使える
env-injector用の環境変数を設定すれば、対象の環境変数が取れる
IAMで許可されているものを取れる
ecsはタスクロールを使う。クレデンシャルキー使っても取れるよｗ
ssm2envとかも同じコンセプト
ヘルパーツールを使うと、ParameterStore/SecretsMangerを使うのは簡単で、KMSのメリットも受けられる

Tips

KMSのアクセスコントロール

明示的なDenyが最強
明示的なallowなないと、暗黙的なDenyで使えなくなる
大切なkeyはマネジメントコンソールで、明示的なDenyを書いたほうが良い
改行を含む値は、CLIを使えば行ける

Encryption Context

マネージメントサービス経由でKMSを使う限りは、よしなにやってくれるので利用はあまり意識しなくていい

QA

env-injectorをローカルで使う時は？

普通に環境変数を切っておいて、本番環境はenv-injectorを使う

ParameterStoreのバージョニングとか使ってる？

使ってない

マイクロサービスを使ってると環境変数が増えるのについて、工夫はある？

CLIで頑張る
あまり
ハシコープVault

データベース暗号化はどのレイヤーでやる？
アプリレイヤーで暗号化してると、DBクエリーで検索できない

検索しないものは、env
普通の個人情報なら、透過的暗号化ではないか？

現場感のある濃いピッチでした！
次回も楽しみですね！

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