このドキュメントについて
- 3/10に開催されたJAWS DAYSの書き殴りメモ
[Serverless] Enterprise Serverlessを実現するための信頼性エンジニアリング
- SERVERLESSってなんだっけ
- サーバーの管理の必要がない
- FaaS,BaaSの2つから構成される
- ゼロサーバーオペレーション(オペレーション自体がなくなるわけではない。あくまでサーバー運用部分がなくなる)
- 使った時間分だけの課金
- その他 CNCFのwhite paperに色々載ってる
- イベント・ドリブンなワークフロー
- SERVERLESSの信頼性とは？
- RASIS
- 信頼性
- 可用性
- 保守性 障害時に修正できるかどうか
- 保全性
- 安全性
- SERVERLESSでの信頼性を担保することの難しさ
- 強くプラットフォームやサービスに依存する
- ログのトレーサビリティ
- RDBとの相性の悪さ
- FaaSのよくある課題
- テストどうやってやる？
- functionの粒度はどうする
- function間、backendとの協調、メッセージング
- エラーハンドリング
- ログのトレーサビリティ
- 監視どうやってやるの
- BaaSの課題
- どうやってサービスを選定する？
- サービスが落ちた時にどうする
- 監視どうする
- FaaSをどう捉えたらよいか
- コンテナ内で非同期に呼び出される関数
- BaaS
- フルマネージドで抽象化されたミドルウェアやライブラリ
- つまりサーバーレスとは、抽象化されているだけの関数やミドルウェアであると捉えられる
- よって、信頼性も今までの考え方を適用して作ることができる
- 考え方
- シンプルにたもつ
- functionの数が増えることを恐れる必要はない
- 複雑さが増さないようにする
- シンプルにたもつ
- RASIS
- SERVERLESSの設計
- イベント、データは同じ方向に流す
- これにより自然と非同期処理になる
- 結果が必要なら同期で返さず取りに行かせる
- ただ、ポーリングで取りに行くのではなく、プッシュで知らせてあげるのがよい
- サービス間のエンドポイントは集約する
- 一連のイベントには必ず同じＩＤを付与する
- トレーサビリティのため
- ログは集約できている前提
- 実行回数のコントロールに有用
- トレーサビリティのため
- データモデリング
- DynamoDBフレンドリにしておこう
- パーティションキー、ソートキー,LSI,GSI
- ACIDトランザクションがないなかでの整合性確保
- Denormalization
- RDBへの書き込みは非同期で
- DynamoDBフレンドリにしておこう
- テスト
- ユニットテスト is Justice
- Serverless,SAM等のフレームワークを使うとテスト作りやすい
- 継続なE2Eテスト
- トレースＩＤを引き回せるようにしておくことで、E2Eテストができるようになる
- イベント、データは同じ方向に流す
- モニタリング
- 通知をしっかり作りこんでおく
- AWS外のサービスを使う場合は、メトリクスがちゃんと取れるサービスを選ぼう
- まとめ
- サーバーレスは特別なものではない
- すべてはアプリケーションの一部である
- 本当に信頼性が必要な部分は自分で作りこむ
- シンプルに考え、シンプルさを維持する
[Keynote] AWS Technical Evangelists Special talk session スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来
(途中から)
- プログラミングを学び始めるにあたって最適なのは？
- プログラミング言語の選択は重要ではない。重要なのは問題を解決すること。
- コンパイル言語からひとつ、スクリプト言語からひとつを選んで使い始めるとよいかも
- その後に、その問題解決により最適なものに移っていくのがよい
- 将来においてもエキスパートでいるための心がけ
- 過去に執着しない
- 過去から未来へのベクトル、流れを把握し、そのベクトルに自分を合わせていく
- 今起きているテクノロジーシフトをちゃんと理解すること
[Security Slot]AWS x 形式手法で人知を超えたセキュリティを手に入れろ
- IAM運用
- IAM Policy Simulator
- 限界
- 論理的な不整合が検出できない(重複、矛盾の検出ができない)
- IAM以外の要素、セキュリティグループが考慮できない
- 限界
- 人間の直感だけでは限界
- IAM Policy Simulator
- 形式手法
- システムを数学的対象として記述
- モデル検査機Alloy
- 関係論理
- SATソルバにより具体例を発見
- 条件を満たす例を自動で全列挙
- 可視化機能あり
[Security Slot]AWSのマネージドサービスを使ったセキュリティ強化のための自動化 freee坂井学 @manabusakai
- 得意分野
- AWS自動化周り
- ブログ
- はったりエンジニアの備忘録
- freeeのサービス上、情報漏えいだめ
- が、freeeのSREエンジニアは5人のみ
- そうだ、自動化だ
- freeeで実践している自動化3つを紹介する
- CodeBuildを使ったAMIの自動作成
- freeeではEC2はGolden AMI方式で運用
- あらかじめミドルウェア群はインストール済み
- アプリケーションは起動時に最新のものを取得する
- 修正パッチをあてるにはAMIを作りなおす
- 自動化前は、SREが手元のマシンでpacker buildでAMIを作成
- AMIの種類が増えてくると作り直しに時間がかかるようになってきた
- CodeBuild自体はセキュリティのサービスではない
- ビルドごとに個別のDockerコンテナが起動し、複数のビルドを自動化できる
- CodeBuildでpacker buildすれば、SREエンジニアの手を使わずとも修正AMIを作れる
- 自動化の仕組み
- Rubyでシンプルなラッパーを作っただけ。エンジニアがやることを1コマンド実行だけ
- freeeではEC2はGolden AMI方式で運用
- AWS WAFを使った自動ブロック
- 自動化前
- 攻撃を受けないと検知ができず、後手に回る
- 攻撃もとのIPアドレスが頻繁に変わるので、Security Group,NetworkACLで防ぎきれない
- nginxで攻撃元のIPアドレスをブロックしたが、結局Webサーバに負荷がかかる
- 深夜や早朝など手薄な時間に対応が発生する
- AWS WAFは古マネージドのWAFサービス
- CooudFrontとALBに設定できる
- SQLiやXSSといった脆弱性を狙った攻撃、IPアドレスマッチング
- 自動化の仕組み
- WAFのRate-basedルールを活用
- 特定のURLにN分間にN書いのリクエストがあると発動
- 自動的にブロックしてくれるので余裕を持って調査できる
- ALBでブロックするのでWebサーバに負荷がかからない
- WAFのRate-basedルールを活用
- 自動化前
- Guard Duty
- CloudTrail,VPCフローログ、DNSログを収集して脅威を検出してくれる
- ただし、通知はしてくれないのでCoudWatc Eventsからlambdaを起動してSlackにwebhook通知
- 他にも様々なセキュリティ対策を施している
- 多層防御が重要
- まとめ
- アイデア次第でセキュリティ強化も自動化もできる時代
コンテナを守る技術2018
- Ryo Nakamaru jaws-ug コンテナ支部 @pottava
- コンテナ使っている人はセキュリティ対策はしていますか？
- DockerHubにあがっているイメージのうち、公式のものも100%安全とはいいきれない
- ＴａｇｓタブのScannedImages
- QUAY
- 仮にベースイメージが安全だとしても、納品されたイメージが安全かどうか？
- 安心のための3つの問い
- アプリケーションの詳細な挙動、把握できていますか
- ＡＷＳでのセキュアな構成、設計ができていますか
- セキュリティポリシーをテストする仕組みはありますか
- アプリケーションの詳細な挙動、把握できていますか
- どれくらいのリソースをつかうか
- どこと通信するか
- ファイル書き込みはする？どのディレクトリ以下？
- 内部的に使われるシステムコールは？
- ホストを管理したいケースではAWS ECS/AWS Batch
- アプリケーション専用のネットワーク
- ホストを忘れたい場合はFargate
- ECSタスク定義
- Dockerが本来持つセキュリティオプションも数多く使える
- セキュリティポリシーをテストしよう
- 継続的なチェックが大事
- 変更が加えられた時の都度テストに加え、何もないときも定期テスト
- アプリケーション実行中に攻撃やポリシー違反がないかをモニタ
- 継続的なチェックが大事
- コンテナの守りかた
- ホストとコンテナ
- 守りやすい環境を整える
- セグメントを分け、攻撃対象・感染範囲を限定的に
- クラスタ分割
- ネットワークを分割
- ホストとコンテナ
- スケールアップよりスケールアウト
- 大きいインスタンスに多くのコンテナを積むのか、小さいインスタンスに少ないコンテナを積むのか
- 攻撃の侵入口を減らそう
- セグメントを分け、攻撃対象・感染範囲を限定的に
- 守りやすい環境を整える
- ホスト
- インスタンスハードニング
- ホワイトリストの導入
- パッチ管理、設定変更管理
- セキュリティ製品のインストール
- AWS Inspector有用
- Dockerホストとして大丈夫かを検証するのに、github.com/docker/docker-bench-securityが使える
- AWSとしても推奨している
- ECSエージェント
- ECS_DISABLE_PRIVIKEGED=true
- ECS_SELINUX_CAPABLE=true
- インスタンスハードニング
- VMとDockerコンテナ
- リソースの分離がＶＭほど厳密ではない
- きちんと自分で設定していく
- ulimits制限
- memory指定
- 必要なリソースを事前に計測しておくことで安心間
- READONLY
- マウントしたディレクトリ以外の書き込み禁止とか
- マウントしたディレクトリを書き込み禁止にしたり
- ルートユーザは使わない
- アプリケーションにあった方法で
- DockerfileのUSER命令でデフォルトユーザを変更
- タスク定義のuserで実行時のユーザを強制
- entrypoint.shとgosuの組み合わせ
- etc.
- アプリケーションにあった方法で
- 実行ファイルの管理
- 不要なファイルは削除、無効化
- 利用するバイナリだけをイメージに入れる
- 不要なファイルは削除、無効化
- 通信を制限する
- システムコールを制限する
- 本当はseccompを使いたいが、ecsは未対応
- ライフサイクル
- テスト
- Static Application Security Testingツールの利用
- CoreOSのClairとか
- Dockerイメージのポリシーを定義＆チェック
- GoogleCloudPlatform/container-structure-test
- Static Application Security Testingツールの利用
- デプロイ後のチェック
- aqua等のＳａａＳを使うとか。
- ECRのイメージ解析
- 実行時防御
- IAM,KMSと統合されたコンテナレベルのRBAC,秘密情報管理
- aqua等のＳａａＳを使うとか。
- テスト
- 秘密情報・接続情報の与え方
- 少し前まで
- S3+IAM Role
- 今風な方法は？
- SSM Parameter Store & KMS & IAM Role
- 少し前まで
- ホストとコンテナ
先進ユーザーが斬るAWSのIoT/AIそこんとこどうなの？
- パネリスト
- フジテック友岡 @TomookaKenji
- ハンズラボ長谷川
- IT酒場放浪記
- ヤンマー大林
- amazon 榎並
- モデレータ 辻一郎
- re:Invent2017で発表されたIoT/AIのサービスをおさらい
- SageMaker
- 古マネーじ度機械学習
- Amazon Kinesis Video Streaming
- Amazon Rekognition Video
- DeepLens(開発用デバイス。商用では使えないよ！日本にはまだ来てない)
- Amazon Transcribe
- Amazon Comprehend
- AWS Device Management IoTデバイスの管理
- AWS Device Defender IoTデバイスのセキュリティ
- AWS IoT Analytics
- Amazon FreeRTOS 組み込み向けOS
- ソラコムの人によると、これはまだ人類には早い(扱いが難しい)らしい
- SageMaker
- 最新トレンド IoT/機械学習ソリューション
- エッジコンピューティング x 機械学習
- エッジコンピューティング
- AWS Greengrass
- GREENGRASS ML INFERENCE
- エッジ上で推論処理
- (demo)
- amazon go
- 各種認識技術を活用
- Computer Vision
- Deep Learning
- Fusion Sensor
- Kinesis video Streamsを使ってビデオストリームを収集
- 各種認識技術を活用
- ディスカッションテーマ
- Amazon Goは未来なのか？世界を変えるものか？
- 日本でもローソンやファミリーマートでも電子タグ(RFID)を使って無人レジを実現しようとしているが…
- コンビニのユースケースはamazon Goみたいなのがよいだろうが、アパレルはRFIDで十分なのではないか
- チロルチョコの認識が無理だからコンビニへのAmazon Go無理というのは筋が悪い。商品の方が合わせたらいい。
- IoT/AIによってイノベーションが起きる領域はどこ？
- 定型作業のところ。人が手間かけて人海戦術しているところ、プロセスに時間かかってるところ
- 超カスタマイズが必要なサービス
- 介護とか
- モノが自動化されたさきに、コトの自動化
- IoT/AIは人間の仕事を奪うのか？
- 東ロボくん の受験の話 偏差値57ぐらいまでいった
- AIは、意味を理解しない
- しかし、偏差値57まで行ったということは、そこに受かることができない8割の人間のやることは代替されてしまうのでは
- 代替されちゃうと思う
- 記憶をもとに判例から判定をしようとするものはAIに負ける
- 人間が価値を発揮できるところは？
- エモーショナルな領域
- 東ロボくん の受験の話 偏差値57ぐらいまでいった
- Amazon Goは未来なのか？世界を変えるものか？
- ヤンマーの取り組み
- 施設園芸の環境制御と植物生育管理
- Yanmar IoT Smart Greenhouseテストベッド
- 画像による成長判定
- エッジ処理制御
- スマート養液システム
- 生育予測
- 環境センシング
- 自家熱電併給
- Yanmar IoT Smart Greenhouseテストベッド
- ディスカッション
- 農業のマネタイズは難しそうだが
- いまのところ赤字だ
- 面白い領域なので今後に期待したい
- 農業のマネタイズは難しそうだが
- 施設園芸の環境制御と植物生育管理
- フジテックの取り組み
- エレベータの故障に関するデータ収集
- 気温が高いと故障しやすい気がする
- センサーでデータ取り
- クラスメソッド 気温データ収集基盤
- KYOSO 電圧データ収集基盤
- センサーでデータ取り
- 気温が高いと故障しやすい気がする
- 海外のエレベータの運行状況を日本でモニタリング
- SORACOM,AWS
- 今までコストがかかっていたところを安価にできるようになってきている
- IoTプロジェクトの進め方
- ROIをトワないPoCを社員教育として始めること
- 動くモデルをまず作ること
- 社内で客を一人みつけること
- 動くモデルができたら車内外に見せびらかすこと
- ギリギリまで「検証です」を貫くこと
- 一つ一つの失敗は成功への学びである
- エレベータの故障に関するデータ収集
- 東急ハンズの取り組み
- システムが100%AWSになった
- Amazon Go
- お客さんが「買わなかった」というデータが取れるのがRFIDの無人レジと違うところ