情報セキュリティ入門

技育CAMPアカデミアに登壇した際の資料です。
セキュリティの一般論を確認した上で、実際の開発時に重要となる様々な項目を具体的に見ていきます。また実際の設定例としてAWSの事例を紹介もしています。
https://talent.supporterz.jp/events/dbc60816-5c7c-4936-95ba-43c08740f8a7/

Transcript

1. © 2024 Finatext Holdings Ltd. 情報セキュリティ入門 2024/11/21 株式会社ナウキャスト 大野巧作 / @Kevinrobot34 技育CAMPアカデミア
2. © 2024 Finatext Holdings Ltd. みな ん、セキュリティを考えな ら 開発 てま ？ 1
3. © 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 2
4. © 2024 Finatext Holdings Ltd. 1. イントロダクション 自己紹介 • 名前：大野巧作 ◦ 大体けびんと呼ばれていま ◦ X / GitHub / Zenn / SpeakerDeck などは @Kevinrobot34 • 役職：Data Engineer / Data Platform Engineer @ Nowcast ◦ POSデータのパイプライン作成・運用 ◦ Snowflake x dbt x Terraform な社内データ基盤構築・運用 ◦ 2020年卒の社会人５年目で 3 会社の出張でSnowflake Summit に行っ 時の写真→
5. © 2024 Finatext Holdings Ltd. 1. イントロダクション Finatext グループ紹介 クラウドネイティブにFinTech領域でサービス開発を ている会社で 。 セキュリティに厳 い金融領域で日々開発を ていま 。 4 主要事業会社 • 株式会社Finatext • 株式会社ナウキャスト • 株式会社スマートプラス（証券会社） • スマートプラス少額短期保険株式会社 • 株式会社スマートプラスクレジット 2013年 12月 設立 2023年12月現在 社員数 300名 ※東京証券取引所　 グロース市場（証券コード :4419） 上場 2021年 12月
6. © 2024 Finatext Holdings Ltd. 1. イントロダクション 本日の流れ セキュリティの一般論を確認 つつ、設定 べ 各項目を具体例を交えな ら紹介 てい ま ！ 内容 多いので一度で全て理解 るというよりは、ま は雰囲気を掴んで イメージで聞いてい と良い と思いま 。資料は公開 るので、今後も定期的に振り返ってみて い！ 5 セキュリティ一般論 • セキュリティの3+4要素 • 多層防御 • ゼロトラスト • 予防的統制・発見的統制 セキュリティ各論 • ポート/コンテンツを不必要にインターネット に公開 ない • 通信時・保存時の暗号化 • 認証・認可 • 最小権限の法則 • ユーザーアカウントを複数人で共有 ない • システム操作のトレーサビリティを確保 る • バックアップは取りま ょう • 認証情報や機微な情報はコミット ない
7. © 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 6
8. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティとは JIS Q 27000 という情報セキュリティマネジメントシステム(ISMS)関連規格に いて、 情報セキュリティは 情報の機密性、完全性及び可用性を維持 る と。 注記： らに真正性、責任追跡性、否認防止、信頼性などの 　特性を維持 る とも含める ともある。 と定義 れていま 。 7
9. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 • 機密性 (Confidentiality) ◦ 「認可 れていない個人、エンティティま はプロセスに対 て情報を使用 、ま 開 示 ない特性」 ◦ 要はデータ 秘匿 れ守られている と ◦ 関連技術：認証・認可、暗号化、など ◦ 機密性 担保 れていないとどうなるの ？ ▪ 機密情報 流出 て まう • 完全性 (Integrity) • 可用性 (Availability) 8
10. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 • 機密性 (Confidentiality) • 完全性 (Integrity) ◦ 「正確 及び完全 の特性。」 ◦ 要は情報 改竄 れ り消去 れ り に、正確 つ完全に残っている と ◦ 関連技術：ハッシュ、署名、メッセージ認証符号、など ◦ 完全性 担保 れていないとどうなるの ？ ▪ データ 改竄 れて まう • 可用性 (Availability) 9
11. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 • 機密性 (Confidentiality) • 完全性 (Integrity) • 可用性 (Availability) ◦ 「認可 れ エンティティ 要求 時にアクセス及び使用 可能である特性」 ◦ 関連技術：冗長化、バックアップ、など ◦ 可用性 担保 れていないとどうなるの ？ ▪ ランサムウェアやDDoSなどの攻撃により、 サービス 停止 情報にアクセスで な なる 10
12. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの追加の４要素 • 真正性 (Authenticity) ◦ 「エンティティは れ 主張 ると りのものであるという特性」 ◦ 真正性 担保 れていないとどうなる ？ ▪ なり ま による詐欺 • 責任追跡性 (Accountability) ◦ インシデント発生時、 の影響範囲や経路をエビデンスとともに厳密に特定で るように なっている と ◦ Traceability とも ◦ 責任追跡性 担保 れていないとどうなる ？ ▪ 何 インシデント 発生 際に、「誰 何を 」の 特定 で ない • 否認防止 (Non-repudiation) • 信頼性 (Reliability) 11
13. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの追加の４要素 • 真正性 (Authenticity) • 責任追跡性 (Accountability) • 否認防止 (Non-repudiation) ◦ 「主張 れ 事象ま は処置の発生、 よび れらをひ エンティティを証明 る 能力」 ◦ 否認防止 担保 れていないとどうなる ？ ▪ 電子契約をあと ら同意 ていないと否認 れる • 信頼性 (Reliability) ◦ 「意図 る行動と結果と 一貫 ているという特性」 ◦ 信頼性 担保 れていないとどうなる ？ ▪ データやシステムにヒューマンエラーやバグ あり、システムに不具合 生 る 12
14. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 攻撃の種類 世の中には様々な攻撃 あり れを知って のも大事で 。 13 不正アクセス • ネットワーク・ポートスキャン • パスワードに対 る攻撃 （総当 り・辞書・リスト攻撃など） なりすまし • マルウェア感染 • ランサムウェア • 標的型攻撃 サービス妨害 • DDoS 脆弱性を狙う攻撃 • SQLインジェクション • XSS • CSRF • ゼロデイ攻撃・RCE • OSコマンドインジェクション サプライチェーン攻撃 …
15. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 多層防御 セキュリティの対策と てよ あるの 入口対策と出口対策で 。 • 入口対策 ◦ も もシステムに侵入 れないように る対策 ◦ 具体例：ファイアウォール、WAF、など • 出口対策 ◦ システムに侵入 れて まっ 場合や内部犯の存在を想定 、機密情報の漏洩などを防 めの対策 ◦ 具体例：暗号化、EDR、MDM、など 近年、情報システムに対 る攻撃手法は多様化 て り、単一のセキュリティ対策 でサイバー攻 撃を防 のは難 なっていま 。 で現在では様々なレイヤで対策を講 て べ という考え 方 一般的で、多層防御と呼ばれていま 。 入口対策も出口対策も れ以外もで る とはやって ま ょう、という とになりま 。 14
16. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 ゼロトラスト 従来のセキュリティは境界型で、ネットワークの内側は安全で、外部は危険とみな 、「信頼で る ネットワーク らのアクセスは許可 れ以外は拒否」などと、境界に応 て適宜対策を講 るもの で 。 、昨今では • 内側であっても、外部 ら一度マルウェア 侵入 て まっ ら攻撃 れるリスク ある • 従業員による不正のリスクもある • クラウドやモバイルデバイスを利用 ると境界は曖昧になる といっ 状況で 。 で「内部ネットワーク らのアクセス ら安全」と信頼 るのではな 、何も信頼 常に検 証（認証・認可）を適切に行い安全性を担保 よう、というゼロトラストセキュリティという考え方 広まっていま 。 15
17. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 セキュリティの対策の他の分類の仕方と て予防的統制と発見的統制 ありま 。 • 予防的統制 ◦ 単に予防とも。英語では Preventative Controls ◦ 想定 れる危険なイベント・行動・問題を定義 、 の発生をで る限り予防 るもの ◦ ネットワークへの不正アクセスや、意図 ないシステムの変更を防 、第一の防御手段 ◦ 具体例 ▪ 権限昇格 で ないように る ▪ 監査ログはシステム管理者であっても削除で ないように る ▪ 削除系など影響 大 いAPIは基本的には使えないように る ▪ 特定のリージョン以外でクラウドを利用で ないように設定 る ◦ AWS では Organization SCPs という機能を利用 る とで、組織内で予防的統制を設定 る と 可能で 16
18. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 セキュリティの対策の他の分類の仕方と て予防的統制と発見的統制 ありま 。 • 発見的統制 ◦ 単に発見や検知とも。英語では Detective Controls ◦ セキュリティに関わるイベント 発生 際に、 問題の早期検知と記録を行い、進行中のインシデントに 対 て関係者にアラートをあ るような統制 ◦ 予防的統制を り抜 セキュリティ問題を ユーザーに通知 る、副次的な防衛手段 ◦ 具体例 ▪ ルートアカウントの利用や 不正ログインと思われる認証の通知 ▪ 影響の大 いAPI 利用 れ 際の通知 17 Finatext での発見的統制のSlack通知のサンプル
19. © 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 予防的統制と発見的統制は両方とも設定 て べ で 。 • 予防的統制のみに 場合 ◦ 予防的統制の設定ミス あると、 れを り抜 て攻撃 れるリスク ある ◦ 対象によっては既存のサービス・仕組みでは実現で ない場合もある ◦ 予防的統制は権限を剥奪 る形で実現 る め、強 やり て まうと開発のアジリティ 下 って まっ り る ▪ 適用範囲は適宜考える と 大事 • 発見的統制のみに 場合 ◦ 何 重要な事象について早めに気付 る とは良い 、 も も れ 起 ないように 方 安全 18
20. © 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 22
21. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 はじめに らはセキュリティで気に べ トピックを細 見てい ま 。 トピック とに以下の内容を紹介 ま 。 • な やるの ？ • 対応 る要素 • 理解 べ 概念 • リスクの実例 • 設定例 23
22. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない • な ？ ◦ インターネットには、不必要に公開 れているポート ら不正にデータを取得 ようと る 仕組み 大量に稼働 ていま 。 ◦ HTTPのエンドポイント でな 、MySQLやRedisやMongoDBやElasticsearchといっ データベースに対 ても んな仕組み 動いていま 。 ◦ 仮に認証 っていても、認証強度 弱 れば突破 れま 、未適用のパッチによって 稼働 ているサーバーに侵入 れる ともありま 。 • 対応 る要素：機密性 • 理解 べ 概念 ◦ IPアドレス・ポート ◦ ファイアウォールなどネットワークの各種設定 24
23. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない • 設定例 ◦ security group の設定 ▪ ポート番号は必要なものを明示 るように ま ょう ▪ ソースはIPアドレスを指定 り、別の security group を指定 るように ま ょう • 特にインバウンドルールで 0.0.0.0/0 に て まうと インターネット らアクセスで て まう 25 良くない設定例
24. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない • 設定例 ◦ S3 の “public access block” ▪ S3バケットをインターネットに公開 る どう の設定 ▪ S3のオブジェクトを直接インターネットに公開 る必要 ないユースケースは多いので 適宜見直 ま ょう ◦ RDS の “public accessible” ▪ れ オンになると public ip 割り当てられる ▪ らに public subnet に配置 れて り、 security group でポート 解放 れていると インターネット らDBにアクセスで るようになって ま ▪ 多 の場合 DB を直接インターネットに公開 て 必要はないので、 各種設定を見直 ま ょう 26
25. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ② 通信時・保存時の暗号化 • な やるの ？ ◦ PC らサーバーまでの経路や、システムへの物理的なアクセスで、 コンテンツを盗聴 れ り改 ん れ り るのを防 め • 対応 る要素：機密性・完全性 • 理解 べ 概念 ◦ 通信時の暗号化と保存時の暗号化 ▪ 暗号化の対象データは、 主に "通信時" と "保存時" に分 て考える と で る。 ▪ 通信時の暗号化の技術 TLS等 ▪ 保存時の暗号化の技術 FileVault 2等 ◦ 通信の経路 ▪ ローカルPC らAWSのインスタンスへのアクセス ▪ AWSのインスタンス ら外部のAPIを利用 る時の通信 ▪ … 27
26. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ② 通信時・保存時の暗号化 • 理解 べ 概念 ◦ 保存場所 ▪ AWS であれば S3 / RDS / EC2 / EBS など ▪ ローカルPC ▪ … ◦ 暗号アルゴリズム ◦ 鍵の管理 ◦ 暗号化のレイヤー ▪ ディスク暗号化 / ファイルシステム暗号化 / ファイルベース暗号化 / カラムレベル暗号化 ... 等 ◦ 暗号スイート / Cipher suite • 設定例 ◦ 多岐に渡るので略 28
27. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 • な やるの ？ ◦ 適切な人・プロセスに適切な権限を与える め • 対応 る要素：機密性・真正性 • 理解 べ 概念 ◦ 認証と認可 違う と ◦ 多要素認証 ◦ 長期的・短期的な認証情報 ▪ IAM User と IAM Role の使い分 ◦ アクセス制御モデル ▪ DAC / RBAC / ABAC • リスクの実例 ◦ 弱いパスワードを利用 てい とによる、アカウントの不正利用 29 『AWSの薄い本　IAMのマニアックな話』より
28. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 • 設定例 ◦ 多要素認証 ▪ パスワードによる知識認証とワンタイプパスワードによる所有物認証を組み合わ 、 認証の強度を上 る 30 Step1: 知識認証 Step2: 所有物認証 Google Authenticator などの スマホアプリで生成 れ MFAコードを入力
29. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 以前の技育CAMPアカデミアで認証認可や最小権限の法則などについて話 ているので 以下の資料も 覧 い！ 31 https://speakerdeck.com/kevinrobot34/introduction-aws-i am-3a810adc-5172-4460-9721-0041456eb2bf
30. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ④ 最小権限の法則 • な やるの ？ ◦ インシデント 発生 時に攻撃者 で る とを少な て とでリスクを減ら ◦ 開発環境で作業 るつもり 本番環境宛にコマンドを実行 て まうといっ ヒューマンエラーを防 • 対応 る要素：機密性 • 理解 べ 概念 ◦ 定義的な最小性 ▪ 実際に利用 る操作の権限 を付与 る、という考え方 ▪ 例えばデータの読み込み権限のみ必要な場合には書 込み権限などは付与 ない ◦ 時間的な最小性 ▪ 強い権限 必要なユースケースもも ろん存在 る 、 の権限 常に必要な とは基本的にない ▪ 実際に作業を る間 強い権限を付与 る、という考え方 32
31. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ④ 最小権限の法則 • 理解 べ 概念 ◦ Two-Person Integrity (TPI) ▪ 重要なデータへのアクセスや、リスクの高いオペレーションに関 て、単独での実行を 不可に 、2人以上の関与を必須と るアクセス管理の手法。別名Two-Person Rule。 相互牽制の力学 • 設定例 ◦ Finatext の TARP という仕組み ▪ Temporary AssumeRole Policy ▪ 時間的な最小性とTPIを実現 る ◦ Google Cloud の PAM (Privileged Access Manager) 33
32. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ④ 最小権限の法則 TARP など Finatext でのセキュリティについては弊社エンジニアの以下の資料も 覧 い！ 34 https://speakerdeck.com/taiki45/efficient-platform-for-security-and-compliance-89d1ad22-14d6-44df-ab7e-dc4ca7fb470c
33. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑤ ユーザーアカウントを複数人で共有しない • な やるの ？ ◦ も も多 のサービスに いて利用規約でアカウントの共同利用は禁止 れている ◦ アカウント 共有 れているとログの有効性 下 る ▪ あるユーザーアカウントのログを見ても「誰」 アクセス の は分 らない • 対応 る要素：真正性・責任追跡性 • リスクの実例 ◦ Xを複数人で運用 て り、パスワードの管理も杜撰で、不正っぽいアクセス あっ 時に 本当に不正アクセス わ らない ◦ あるユーザーアカウントのパスワード 共有 れて り、長期間変更も れて ら 、 退社 メンバーでも利用 ようと思えばで て まう ◦ 開発者みんな 使っている共有アカウント 不正利用 れ め、 エンジニア全員の端末をフォレンジック る必要 ありま 、などと 調査範囲 無駄に広 って まう 35
34. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑥ システム操作のトレーサビリティを確保する • な やるの ？ ◦ インシデント発生時、 の影響範囲や経路をエビデンスとともに厳密に特定 る め • 対応 る要素：責任追跡性 • 理解 べ 概念 ◦ ログの種類 ▪ 接続ログ ▪ 認証ログ ▪ 操作ログ ▪ 変更ログ ▪ 通信ログ ▪ エラーログ ▪ イベントログ ▪ アプリケーションログ ▪ … 36 https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/centralizing-logs.html
35. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑥ システム操作のトレーサビリティを確保する • 理解 べ 概念 ◦ ログの中身 ▪ 「誰 /いつ/ど ら/何を」行っ 記録 れている とを確認 る ▪ 不必要に機密情報(パスワード等)を含めない ◦ ログをど にどれ らい保存 る ？ ▪ ログの内容や用途によって変わる。法的に求められる期間 違っ りも る。 ◦ At Most Once(最大で1回) / At Least Once(最低1回) / Exactly Once(確実に1回) ▪ ログは、At Least Once or Exactly Once で記録 れる と 望ま い ◦ WORM (Write Once Read Many) ▪ 一度書 込ん データを、消去・変更で ないという性質の と ▪ ログ 改 んで て まってはログの信頼性 ゆらいで まう め • リスクの実例 ◦ AWSのIAM 不正に利用 れ、データベースの個人情報にアクセス れ も れま ん ( 、ログ ないので調査 で ま ん) 37
36. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑥ システム操作のトレーサビリティを確保する 38 https://docs.aws.amazon.com/whitepapers/latest/ microservices-on-aws/centralizing-logs.html • 設定例 ◦ AWS CloudTrail ▪ AWS リソースの操作ログ（APIを叩い ログ） ◦ AWS Config ▪ AWS リソースの変更ログ ◦ VPC flow log ▪ VPC内のIPトラフィックに関 るログ ◦ ALB access log / CloudFron access log / S3 access log ▪ 各種サービスへのアクセスログ ◦ DB (MySQL) の audit log / error log / general log / slow query log ▪ データベースは認証ログを含む様々なログを出力で る ▪ 用途は れ れ どれも取って と 大事
37. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑦ バックアップを取る • な やるの ？ ◦ 自然災害やセキュリティインシデント あってもサービスを復旧可能に る め • 対応 る要素：可用性 • 理解 べ 概念 ◦ バックアップの保存 ▪ AWSであれば「どのアカウント」の 「どのリージョン」に保存 る ◦ バックアップの頻度・保存期間 • リスクの実例 ◦ 不正アクセス 攻撃者による ランサムウェア攻撃によって、サーバのデータなど 暗号化 れて まい、データ 利用 不可も は失われて まう。バックアップ な 復旧も不可能。 39 https://aws.amazon.com/jp/blogs/storage/secure-data-recovery-with-cros s-account-backup-and-cross-region-copy-using-aws-backup/
38. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑦ バックアップを取る • 設定例 ◦ AWS Backup ▪ タグを付与 る で簡単にバックアップを取れるように て れるサービス ◦ RDS ▪ backup：1日１度自動バックアップの設定 可能で、 の保存期間も設定可能 ▪ backtrack：指定 時間までDBクラスターを巻 戻 る機能 40
39. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑧ 認証情報や機微な情報はコミットしない • な やるの ？ ◦ パスワードや秘密鍵、APIキーなどに紐づ 権限を悪用 れるのを防 め ◦ Jupyter Notebook などで分析 てい 機微なデータ 漏洩 るのを防 め • 対応 る要素：機密性・真正性 • リスクの実例 ◦ Qiita - GitHub に AWS キーペアを上 ると抜 れるってほんと？？？試 てみよー！ の記 事によると、AWSのアクセスキーを public repo に push ると13分で悪用 れ との と • 設定例 ◦ gitleaks や git-secrets といっ ツールを導入 、pre-commit の hook を設定 る とで コミット前に認証情報や機微な情報 含まれない を確認 、含まれ うな場合にはコミッ ト で ないように る ◦ 鍵のファイルや環境変数を設定 るファイルは .gitignore に設定 て 41
40. © 2024 Finatext Holdings Ltd. 3. セキュリティ各論 まとめ • セキュリティの一般論を整理 ま ◦ セキュリティとは機密性・完全性・可用性を担保 る とで ◦ 多様な攻撃、多層防御、ゼロトラスト、予防的統制・発見的統制といっ セキュリティで重 要となる考え方を確認 ま • クラウドでセキュアに開発 る際の様々なトピックを確認 ま ◦ ポート/コンテンツを不必要にインターネットに公開 ないように ま ょう ◦ 暗号化、認証・認可、ログの取得、バックアップの取得は っ りやりま ょう • セキュリティは幅広い技術領域 関係 、非常に難 いで 、 一般論と個別の具体的な論点と両面 ら学習 てい とで、徐々に理解 深まるは で ◦ 継続的に振り返り、セキュリティを意識 て開発で るエンジニアになりま ょう！ 42
41. © 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 43
42. © 2024 Finatext Holdings Ltd. 4. Appendix 参考書籍 • 『図解即戦力 暗号と認証の みと理論 っ りわ る教科書』 成 滋生 • 『暗号技術入門 第3版　秘密の国のアリス』 結城 浩 • 『AWSの薄い本　IAMのマニアックな話』 佐々木拓郎 • 『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』　徳丸 浩 • 『イラスト図解式 の一冊で全部わ るネットワークの基本 第2版』 福永 勇二 44
43. © 2024 Finatext Holdings Ltd. 4. Appendix 参考リンク • https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/security-control-types.html • https://speakerdeck.com/kevinrobot34/introduction-aws-iam-3a810adc-5172-4460-9721-0041456eb2bf • https://speakerdeck.com/taiki45/efficient-platform-for-security-and-compliance-89d1ad22-14d6-44df-ab7e-dc4c a7fb470c • 45