はじめに
今回は1/29(水)に開催されたJAWS-UGの初心者支部に参加してきたので内容を書きます。
メモ代わりに書いたので、見づらかったらすみません。。
イベント情報はこちら
jawsug-bgnr.connpass.com
JAWS-UG 初心者支部についてはこちら
jawsug-bgnr.connpass.com
タイムテーブル
connpassに載っていますがタイムテーブルは以下のようになっています。
内容
ミニハンズオン：AWSアカウントを作ったら最初にやるべきこと-セキュリティ編-
登壇者：JAWS初心者支部運営 迫 康晃さん
好きなAWSサービス：Lambda、CDK
実施概要
- IAMのセキュリティ周りの内容が中心
ハンズオン手順
アジェンダ
詳細は上記のQiitaに書いてありますが、一応ハンズオン手順のアジェンダだけ記載しておきます。
- ルートアクセスキーの削除
- ルートアカウントのMFA有効化
- パスワードポリシーの変更
- IAMグループの作成
- IAMユーザーの作成
- CloudTrailの有効化
- GuardDutyの有効化
- GuardDutyのサンプル表示
- 課金リソースの削除
- CloudTrailの無効化
- S3バケットの削除
- GuardDutyの無効化
所感
ハンズオンは迫さんが事前にQiitaに書かれた記事を元に進めるやり方で、中々に新鮮でした。
内容としては、今日アカウントを作成しましたという初心者の人から、前々からアカウントは作成していたけどなんとなくでIAM管理をしていた人にとってはとても役に立つ内容でした。
かくいう自分もあまり意識せずに使っていた部分が多かったので、改めて注意する点や設定すべき内容を確認することができました。
セッション①：Fin-JAWSの紹介と金融の現状
登壇者：Fin-JAWS支部運営 釜山 公徳さん(日本電気株式会社)
Fin-JAWSの紹介
Fin-JAWSについて
- 金融とFinTechのJAWS-UG
- 金融やFinTechに興味があれば参加OK
- 銀行、証券、保険といった金融事業やFinTech企業における... ※メモしきれなかったです
金融のクラウド
- AWSの金融の歴史
MUFGショック
→大手銀行における初事例
→クラウドが加速化に寄与
金融分野におけるクラウド導入状況
→都銀、信託では平成28年時にクラウド導入率100%
→基幹系業務システムへのクラウド導入状況は低い
→クラウドへの理解が中々進んでいない
政府情報システムにおけるクラウドサービスの利用に係る基本方針
→基本方針にクラウド・バイ・デフォルトの原則が記載
→具体方針に検討プロセスが記載されている(SaaSを活用する等)
宣伝
JAWS DAYS 2020が開催される
日時は3/14(土) 10:00~19:00
セッション②：データはどこからくるの？〜AWSとオンプレとの違いで学んだあれやこれ〜
登壇者：大熊 香里さん(株式会社QUICK)
好きなAWSサービス：Lambda
資料はこちら
自己紹介
- 2018年秋に初めてAWSの仕事
- 2019年9月にSAA取得
- 2019年12月にre:Invent参加
データはどこからくるの？
- 数百か所以上の場所から、色々な方法で、色んなフォーマットでデータを取得
- 従来は人手でシステムに出力していた
- 現在はAWSで半自動化した(Lambda)
- Lambdaは用途ごとに準備して組み合わせて利用
- 数人月は削減できた
大失敗
検証のためにLambdaを実行したところ、同時実行のLambdaを食いつぶした
→提示起動の他のLambdaが動かなかった
→対象のLambdaの同時実行数を制限
→動かしたいLambdaが動かない。。
→実行待ちが続いた結果、読取りの速度が低下
その失敗を踏まえて事前にしておいたほうが良かったと思ったこと
→同時時刻数の上限を上げておく
→SQSなどを入れてキューをハンドリングできるようにする
→アカウント全体でLambdaのThrottles検知の仕組みを入れておく
→必ず動かす必要があるLambdaは同時実行の予約をしておく
→対象に動く可能性があるLambdaにも同時実行の予約をしておく
所感
Lambdaはそこまで大規模に使ったことなかったですが、今回のような同時実行数の失敗例を聞くとその重要性がよくわかりました。
様々なデータを加工する際にどのようにLambdaを使用しているのかは気になりました。(フォーマットごと？データごと？)
セッション③：FISCから学ぶAWSセキュリティことはじめ
登壇者：新井 雅也さん(野村総合研究所)
資料はこちら
speakerdeck.com
自己紹介
主に金融系のお客様を担当
AWSとFISCガイドラインの関係性
セキュリティはお客様の中でも最も重要なものの1つ
→AWSが提供しているセキュリティリファレンスもある
→AWS利用者側の対応が必要な項目が多数あり(責任範囲)
→FISCガイドラインを俯瞰するとセキュリティ/運用実装のポイントが見えてくる
FISCガイドライン準拠のユースケース
NWやデータの暗号化はもちろん、データの内容によってはAppレベルで暗号化
→ASMで証明書を発行し、インターネット通信を暗号化
→個人情報等はAppレベルで暗号化
→EBSやデータベース内暗号化
→VPCエンドポイント経由で内部通信化
暗号カギはKMSに集約させるケースが多い。要件に応じてCloudHSMも検討
SSｍのインベントリ情報やリポジトリツールでSQ全体を管理
CloudWatchメトリクスベースでリソース管理
AWSが提供する不正予防＆検出系のサービスは割と手厚い
→WAF、Shield、GuardDutyなど
AWSレベルはIAM、Appレベルは自前で用意することが多い
マルチAZは必須、データ保持要件次第でマルチリージョン化
等
セッション④：マルチアカウント運用のはじめかた（Japan Degital Design）
登壇者：小野 雄太郎 (Japan Digital Design, Inc.)
Japan Digital Design, Inc.
→三菱UFJフィナンシャルグループの子会社
資料はこちら
マルチアカウントとは？
1つの組織で複数のAWSアカウントを使うこと
→部署単位で分ける
→経費の精算単位で分ける
→環境ごとに分ける 等々
マルチアカウントのための機能
AWS Organizations
→AWSアカウントを一括管理する仕組み
→親子アカウントを管理できる
→全アカウントの請求を一括でできる
一括請求
→AWSアカウントの請求と集約できる
OUによるアカウントの管理
マルチアカウントのはじめかた
- ルートAWSアカウントを決める
→権限は強い
→通常利用はしない前提
- AWS Organization有効化
→ルートAWSアカウントで有効化する
- 既存アカウントの招待
→既存のアカウントをOrganizationsに招待する
- OUによる整理
→OUにAWSアカウントを移動する
→階層構造で管理できる
- ルートアカウントでアカウントの追加作成
→作成したアカウントはルートアカウントに紐づく子アカウントとなる
アカウントの分けかた
1つのアカウントを共有するデメリット
→権限の制限が難しくなる
→リソースを間違って削除することができてしまう
AWSの世界で使いやすい分け方を考える
→会社の組織構造で分けるのはお勧めできない
→会社の組織は良く変わる
あとで困らない始めかた
→1アカウント1用途が基本
①ルートアカウント
②IAMユーザ認証アカウント
③セキュリティ通知用アカウント
④検証環境
⑤運用環境
①ルートアカウント
→課金管理
→CloudTrail
→OrganizationAccountAccessRole
②IAM認証アカウント
→組織で使うIAMユーザーを作成
→入退社に合わせたアカウント管理が楽に
③セキュリティ通知用アカウント
→GuardDutyのマスターアカウント
④⑤検証/運用環境
→検証環境用アカウントは開発者事や共有アカウントを用意するケースのどちらもありうる
→運用環境用アカウントはサービスごとにAWSアカウントを分けるとメンテナンス作業の影響をアカウント内に限定できる
実際の利用例
Biz LENDING(オンラインで完結する中小企業向け融資)
→自動で与信結果を返すモデルを開発
→全情報をAWSで分析
→複数のAWSアカウントで管理
→Zonesごとにアカウントを分けることで、アクセスできる範囲を分けている
まとめ
- 1つ1つのAWSアカウントをシンプルに使う
- 偶発的な間違いを防止
- 明日からマルチアカウントへ
