【参加レポ】JAWS-UG情シス支部第30回　#JAWS_UG #AWS

2024年4月27日 20:35

今回は2024年4月15日に開催されたAWSのユーザコミュニティ「JAWS-UG」の情シス支部のイベントにオンライン参加したのでその内容をレポートしたいと思います。

19:30 JAWS-UG情シス支部について運営

運営メンバー全員の掛け声で始まったJAWS-UG情シス支部です。なんと１年３ヶ月ぶりの開催だそうです。渇望のせいなのか１００近くの申込者がいるそうです。

まずはコープさっぽろの山崎さんによる情シス支部の紹介からです。JAWS-UG情シス支部はAWSを自分の会社や組織に導入するにあたっての悩みを共有したり議論したりする場として情シスや現場で手を動かしている人たちの集まりにしたいと開始したそうでユーザー企業でもSIerでも自社開発の人でも良いそうです。

議題としては
・社内システム担当として悩んでいること
・社内でこうやってみたらうまくいくこと
・他社の同じ立場の人に聞いてみたいこと

みんなで議題を持ち寄って議論しましょうという場です

20:00 KAGが関わるアカウント全てにSecurityHubを導入した(い)話 KDDIアジャイル開発センター株式会社若松さん

最初は運営メンバーでKDDIアジャイル開発センターの若松さんからのSecurity Hub導入のお話です。

KAG（KDDI アジャイル開発センター）はアジャイル開発にこだわりKDDIの部署としての10年間の実績のうえ2022年にKDDIの子会社として独立した会社です。（その昔アジャイル研修でお世話になりました）

最近は開発案件が増え、プロジェクトごとにAWSやセキュリティ専門家がいない状態が発生しセキュリティの基準にばらつきが出てしまっていたそうです。それを解決しようとして使ったのがAWS Security Hubです。

AWS Security Hubはセキュリティの様々なベストプラクティスのチェックを自動化して、集約され、定期的な（12Hor24H）セキュリティアラートですべてのAWSアカウントのセキュリティを単一のダッシュボード把握できるツールです。

KAGではKAGのオーガナイゼーションの中にあるセキュリティアカウントに集約する仕組みになっています。外部のプロジェクトアカウントからも人手間かけて集約しています。

SecurityHubでは責任共有モデルのうち「お客様」領域のAWSのサービス設定に関する部分を対象としていて、どこが悪いのかをひと目で具体的にわかるようになります。

SecurityHubの導入にあたっての準備は①クロスアカウント設定の確率②共通コントロールの作成と全アカウントへの提供方法確立③社員向けの説明資料作成が必要になります。

①クロスアカウントの設定の確率
Org外のアカウントはひと手間必要になる
・対象アカウント：SecurityHubを有効化
・管理アカウント：対象アカウントにInvitationを送る
・対象アカウント：InvitationをAccept
・対象アカウント：コントロール設定用IAMロール作成
・管理アカウント：コントロール定義配布〜管理アカウントと管理アカウントの間でコミュニケーションは必要

②共通コントロールの作成と全アカウントへの提供方法確立
Org外のコントロールの設定はAWS公式のサンプルソリューションを使用
・いらないルールを省いて全アカウントに適用

ツールの機能
・Administrater SecurityHubからState Machinをよぶ
・CrossAccountのIAMロールを通しMemberSecurityHubにコントロールを適用
⇒SecurityHubのコントロールがすべて同じになる

社員向けの説明資料作成
・可視化が出来たあとFailに対してどう対処するのか？対処法を含めリスト化
⇒プロジェクトが迷わないような自己解決できるよう

今後
・まだ１プロジェクトしか完了していないので、これから展開する予定
・AWSのセキュリティに係るサービスはまだまだある

まとめ
・AWSのセキュリティ品質を保つためSecurityHubはおすすめ
・クロスアカウント設定はポリシー適用などいくつかの手順を踏む必要あり
・Security Hub以外にもセキュリティに係るサービスがあるので導入したい

20:05 情シスにはStepFunctionsが強力な味方になるのではないか説生活協同組合コープさっぽろ山﨑さん

次はコープさっぽろ山崎さん。テーマはStepFunctionsです

StepFunctions
開発の人用、難しそう、情シスには関係なさそうなイメージ

でも、Lambda書かなくてもAWS APIを呼び出せる⇒使えそう

I AM Identity CenterとQuickSightユーザーのプロビジョニングをStepFunctionsで実装してみた

課題の背景
・2021年から3年くらいQuickSightを使用
・I AM Identity Centerを使用してSSOログイン
・IdpはGoogle WorkspaceでカスタムSAMLアプリを使用
・８部門でQuickSightを使用し横展開中、ユーザ数は2200人⇒もっと増える
・QuickSightで自部門の分析やダッシュボードしか見られないようにしたい

2023年2月頃にStepFunctionsを実装
・I AM Identity Centerを経由してQuickSightへのログインはできる
・QuickSightユーザーの自動生成は出来ない
・QuickSightグループへの関連付けが出来ない

QuickSightのユーザープロビジョニング（BlackBeltから）
２つの方式を要件によって使い分ける
・管理者による事前プロビジョニング
・ユーザー自身による自己プロビジョニング
　⇒大規模利用の場合はやりたくない

AWSさんに相談
Lambdaで自動で自薦プロビジョニングの実装庵

⇒StepFunctionでこれを実装

StepFunctionでの実装
・EventBridgeからStepFunctionsを起動
・QuickSight側で追加すべきグループを取得するため
　aws.sso-directoryのAddMember ToGroupeイベントをトリガー指定
・EvebtBridgeのターゲットでStep Functionsを指定

①idpからSCIMでIAM Identity Centerにユーザ追加、グループ追加でスタート
②湯０座ー情報とグループ情報を取得
③同時に複数のユーザーが追加されることを考慮して並行実行
④QuickSightユーザIDをLambdaで生成（Lambda使用を避けられず）

⑤Lambdaの結果が200かどうかを判定　
　エラーだったらFailで終了、200ならユーザー情報を取得
⑥QuickSightユーザーが存在しているかを判定
　存在しない：ユーザー作成し、グループ追加ステップへ
　存在する：そのままグループ追加ステップへ
⑦QuickSightグループへの追加

ハマったところ
・値を次Stepにわたす際に文字列を連結する方法がわからず
・初回実行時、当時いた1600人分の処理が走ってAPIがコケた
・QuickSightDescfibeUserもコケる
・QuickSightユーザーが存在しない場合にコケる

課題
・利用部門が増えた場合Stepが掛け算で増える、Lambdaの修正も必要

その後アップデート
QuickSightでAWS IAM Identity Centerとの統合の一般提供開始
　⇒新規環境のみで既存の環境には適用されない

まとめ（情シス的StepFunctions）
・使えるAPIはたくさんある、何かしら使える
・手作業が大変なことはStepFunctions二任せよう

最後宣伝です

20:35 - マルチアカウント運営のノウハウあれこれ澤井さん

休憩後のＬＴは初登壇の澤井さん。情シス兼クラウドCoEの澤井さんの発表はテーマはマルチアカウント運営です。

まずはクラウドCoEとして支援していることの紹介です。クラウド未導入から始めて今はアカウント40以上、ユーザー100名以上担っているそうです。

支援内容
日常
・Teamsでアカウントごとの相談窓口
・社内ポータルでのノウハウ共有
・日次、月次でコスト通知
セキュリティ
・SecurityHubからの通知
・GuardDutyからの通知
・行為権限アクセス監視

クラウドCoEはあくまで支援としていたら・・・
⇒知らないところで大変なことになってしまっていた
・サーバレスでやってほしい
・設定ミスのリスク、チェックされずに構築　・・・・

ユーザーがどれだけクラウドを使いこなせるか
・認識にギャップが有る
・クラウドに不慣れ化型も、良かれと思って色々やる方もいる
⇒ユーザーがいきなりクラウドを使えるようになるわけない

対策：とにかく対話する
・月１のペースでショートに話せる環境を作る
・各種ダッシュボードも一緒に確認して気になることは即解決
⇒結果、距離が縮まって、一緒に進めるようになる
　利用者の自主性を引き出すヒアリング方法が大事

学んだこと
・ユーザー主体でCoEは支援・・・自体は間違ってないがお互い歩み寄ろう
・もっと雑にぁいわしてもいいまである
・ユーザ側の知識レベルも上げていく必要がある

20:45 Amazon Bedrockを使って全社員に生成AIサービスを提供したかった話タキヒヨー株式会社ないきさん

次のLTはタキヒヨー株式会社のないきさん。Amazon Bedfockを使って前者に生成AIサービスを提供するお話です。

使用したサービス
・Open AI LINE WORKS Bot
・Amazon Bedrock

ふりかえり
・2022/11/30：ChatGPTリリース
・2023/02/02：GPT Plus登場
・2023/03/01：ChatGPT API公開
・2023/03/06 GPT3.5チャットボット導入
全社員向けに導入（LINE WORKS＋GASベース）

　・通常のChatGPTと同様のBot
　・画像解析できるもの
　　ChatGPTの画像解析はの日本語のラップを作るのがうまいという印象
　・画像生成

課金：それぞれが契約するよりもかなり安い

・2023/11 生成AI体験ワークショップ
　生成AIのサービスを自分のAWSアカウントで構築できる
・2023/11/24 AWS 生成AI WEBアプリ導入
　チャット、文書生成、ようやく、翻訳、画像生成、音声文字起こし

料金：100ドル弱／月
　　　画像生成StableDiffusionが1/3くらい

・2024/03 繊維商社向けカスタマイズ
　４ヶ月ほど開発にかかり4/15にローンチ
　GitHubに公開

　テンプレート共有機能
　　レビューをまとめていくところに生成AIを使う

名古屋の皆さんに展開
　AWSユーザー、LINEWORKSユーザー、学生、新社会人・・

20:55 IaCツールを使って、昔に作ったLambda関数をCDK管理下においてみたアイレット株式会社和田さん

次はJAWS千葉でアイレットの和田さんのLTです。

社内で使っているアプリ
・EC2上で使っているWebアプリ
・EventBridge＋SQS+ぁｍｂだ+S3を構築された定期バッチ
・StepFunctions + Lambdaで構築された他システム連携処理
・Amplifyで構築されたWebアプリ

StepFunctions + Lambdaの他システム連携処理の改修
・Lambda コンソールで手動デプロイが５つにLambdaを追加
・ランタイムバーションが混在
・Distributed Mapを使用したい

検討の結果
⇒いろいろあってCDKのProjectとして全部作り直し・置き換え

ちょうど同時期にAWS 上で Infrastructure as Code (IaC)のアップデート
⇒これを使うしかない

ツールとしての手順
・リソースのスキャン：ボタンをクリックして待つ（1万リソースが12分）
・テンプレート生成：ココが肝、Scanしたリソースを探して選ぶ
・CDK Migrate：AWS CDKのタブに移動してテンプレートをダウンロード
　　　　　　　ほぼ同時期に登場したコマンド
・落としたファイルを置いて、記載してあるコマンドを実行
・(L2 Constructs化) 可読性を上げるため
　　　　　　　L2だとL1の1/4くらいのコードになる

デプロイ時の注意点
Migrateコマンド実行： migrate.jsonというファイルがプロジェクト内に生成
⇒このファイルが残っているとcdk deploy時にとエラーになる

今回の作り直し
・CDK管理化は達成
・デプロイ作業の単純化も達成
　〜いいことづくめで本番リリース＋処理置き換えが完了

まとめ
・IaCツールは既存リソースのAWS CDK等をIaC管理下に置くのに便利
・無料でリソースの洗い出しに便利
・30日後には再スキャンが必要なのでLamdaあたりで定期実行

21:05 塩漬けダメ、ゼッタイ！サポート切れのIaCツールをTerraformに移行した話 KDDIアジャイル開発センター株式会社 SimStaさん

最後はKDDIアジャイル開発センターのSimStaさん。おなじくIaCツールの話です。

入社して真っ先にやったこと
先月KDDIアジャイル開発センターに入社
〜まずは社内のAWSアカウントを眺める
・AdministratorAccessのアクセスキーが無いか
　〜それなりにあった
・コンソール用のIAMユーザーにアクセスキーが付与されていないか
　〜いくつかついていた
・長時間使用されているIAMユーザーがいないか
　〜たくさんいた
・強い権限を持つIAMユーザーにMFAは設定されているか
　〜ほとんど設定されていなかった
・余計な料金を発生させているリソースはないか
　〜とんでもないやつがあった（今回の話）

・２月〜３月間でRDSの請求が400＄⇒735＄
　⇒RDS for MySQL5.7が延長サポートへ突入していた

謎のDroneを撃破せよ
⇒１つのインスタンス「Drone-db」が犯人
・今いる人に知っている人がいない
・セキュリティグループに更新するCI/CDのツール？

Terraform移行
・社内で使われていたIaCユールがTerraformだった
・CloudFormationを普段使っていてTerraformは初めて
・なるべく早く移行を済ませる（スピード優先）

ハマりポイント

・セキュリティグループのルールの書き方が３つある
　記述量と疎結合の度合いが違う

・リソースのimport方法が２種類ある
　コマンドで１つづつ取り込む、
　trファイルにimportブロックを記述してapplyで取り込む

・GitHubActionを動作させるRunnnerが２つある
　GitHubのマネージドRunnner
自前で用意するSelf-Hosted Runnner

GitHub ActionsがApplyする場合Actions終了で作業ディレクトリが削除
　リポジトリのtfstateは更新されず不整合が発生