カピバラ好きなエンジニアブログ

ITのこととか趣味のカメラのことなどを赴くままに書いていきます。カピバラの可愛さこそ至高。

JAWS-UG 初心者支部に参加してきた(Fin-JAWSコラボ&ミニハンズオン会)

はじめに

今回は1/29(水)に開催されたJAWS-UGの初心者支部に参加してきたので内容を書きます。
メモ代わりに書いたので、見づらかったらすみません。。

イベント情報はこちら
jawsug-bgnr.connpass.com

JAWS-UG 初心者支部についてはこちら
jawsug-bgnr.connpass.com

 

タイムテーブル

connpassに載っていますがタイムテーブルは以下のようになっています。
 
f:id:live-your-life-dd18:20200129190532p:plain

内容

 


ミニハンズオン:AWSアカウントを作ったら最初にやるべきこと-セキュリティ編-

登壇者:JAWS初心者支部運営 迫 康晃さん
好きなAWSサービス:Lambda、CDK

実施概要
  • IAMのセキュリティ周りの内容が中心
実施理由
ハンズオン手順

qiita.com

アジェンダ

詳細は上記の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

資料はこちら

www.slideshare.net

自己紹介
  • 2018年秋に初めてAWSの仕事
  • 2019年9月にSAA取得
  • 2019年12月にre:Invent参加
アジェンダ
  • データはどこからくるの?
  • SaaSのよさ
  • 大失敗
データはどこからくるの?
  • 数百か所以上の場所から、色々な方法で、色んなフォーマットでデータを取得
  • 従来は人手でシステムに出力していた
  • 現在はAWSで半自動化した(Lambda)
  • Lambdaは用途ごとに準備して組み合わせて利用
  • 数人月は削減できた
SaaSのよさ
  • 構築作業が不要
  • リプレース、セットアップ不要
  • クラスタ・同期の設定に時間がかからない
  • 高い可用性
  • 筐体全体の性能を気にしなくていい
  • ハード障害の緊急電話が来ない
大失敗

検証のためにLambdaを実行したところ、同時実行のLambdaを食いつぶした
→提示起動の他のLambdaが動かなかった
→対象のLambdaの同時実行数を制限
→動かしたいLambdaが動かない。。
→実行待ちが続いた結果、読取りの速度が低下

その失敗を踏まえて事前にしておいたほうが良かったと思ったこと
→同時時刻数の上限を上げておく
→SQSなどを入れてキューをハンドリングできるようにする
→アカウント全体でLambdaのThrottles検知の仕組みを入れておく
→必ず動かす必要があるLambdaは同時実行の予約をしておく
→対象に動く可能性があるLambdaにも同時実行の予約をしておく

所感

Lambdaはそこまで大規模に使ったことなかったですが、今回のような同時実行数の失敗例を聞くとその重要性がよくわかりました。
様々なデータを加工する際にどのようにLambdaを使用しているのかは気になりました。(フォーマットごと?データごと?)
 


セッション③:FISCから学ぶAWSセキュリティことはじめ

登壇者:新井 雅也さん(野村総合研究所)

資料はこちら
speakerdeck.com

自己紹介

主に金融系のお客様を担当

FISCガイドラインとは

金融は法の準拠が厳しい
→準拠すべきシステムのガイドラインが存在
→FISCが安全対策基準を策定
→金融系サービスはFISCガイドラインの準拠が重要

AWSとFISCガイドラインの関係性

セキュリティはお客様の中でも最も重要なものの1つ
AWSが提供しているセキュリティリファレンスもある
AWS利用者側の対応が必要な項目が多数あり(責任範囲)
→FISCガイドラインを俯瞰するとセキュリティ/運用実装のポイントが見えてくる

FISCガイドライン準拠のユースケース

NWやデータの暗号化はもちろん、データの内容によってはAppレベルで暗号化
→ASMで証明書を発行し、インターネット通信を暗号化
→個人情報等はAppレベルで暗号化
→EBSやデータベース内暗号化
VPCエンドポイント経由で内部通信化

暗号カギはKMSに集約させるケースが多い。要件に応じてCloudHSMも検討

SSmのインベントリ情報やリポジトリツールでSQ全体を管理

CloudWatchメトリクスベースでリソース管理

AWSが提供する不正予防&検出系のサービスは割と手厚い
→WAF、Shield、GuardDutyなど

ウイルス対策SWはサードパーティ製を使用

AWSレベルはIAM、Appレベルは自前で用意することが多い

マルチAZは必須、データ保持要件次第でマルチリージョン化

まとめ

パブリッククラウドはインターネット越しの利用が前提
→どのようにして多層防御を行うか

まずは実装可能な項目をすべて洗い出してみることも大切
→コストとのバランス

所感

とても駆け足なLTでしたが、内容的にはかなり濃いものでした。
セキュリティが厳しい金融系の中でどのようにAWSを使用しているかは知れて良かったです。
 


セッション④:マルチアカウント運用のはじめかた(Japan Degital Design)

登壇者:小野 雄太郎 (Japan Digital Design, Inc.)

Japan Digital Design, Inc.
三菱UFJフィナンシャルグループの子会社

資料はこちら

www.slideshare.net

マルチアカウントとは?

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アカウントをシンプルに使う
  • 偶発的な間違いを防止
  • 明日からマルチアカウントへ
所感

組織の構造=AWSで最適なアカウント管理ではないというのは確かにと思いました。
確かに会社ってよく部署移動などあるので、それはそうですよねと納得しました。