© 2024 Finatext Holdings Ltd. 情報セキュリティ入門 2024/11/21 株式会社ナウキャスト 大野巧作 / @Kevinrobot34 技育CAMPアカデミア

© 2024 Finatext Holdings Ltd. みな ん、セキュリティを考えな ら 開発 てま ？ 1

© 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 2

© 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 に行っ 時の写真→

© 2024 Finatext Holdings Ltd. 1. イントロダクション Finatext グループ紹介 クラウドネイティブにFinTech領域でサービス開発を ている会社で 。 セキュリティに厳 い金融領域で日々開発を ていま 。 4 主要事業会社 • 株式会社Finatext • 株式会社ナウキャスト • 株式会社スマートプラス（証券会社） • スマートプラス少額短期保険株式会社 • 株式会社スマートプラスクレジット 2013年 12月 設立 2023年12月現在 社員数 300名 ※東京証券取引所　 グロース市場（証券コード :4419） 上場 2021年 12月

© 2024 Finatext Holdings Ltd. 1. イントロダクション 本日の流れ セキュリティの一般論を確認 つつ、設定 べ 各項目を具体例を交えな ら紹介 てい ま ！ 内容 多いので一度で全て理解 るというよりは、ま は雰囲気を掴んで イメージで聞いてい と良い と思いま 。資料は公開 るので、今後も定期的に振り返ってみて い！ 5 セキュリティ一般論 ● セキュリティの3+4要素 ● 多層防御 ● ゼロトラスト ● 予防的統制・発見的統制 セキュリティ各論 ● ポート/コンテンツを不必要にインターネット に公開 ない ● 通信時・保存時の暗号化 ● 認証・認可 ● 最小権限の法則 ● ユーザーアカウントを複数人で共有 ない ● システム操作のトレーサビリティを確保 る ● バックアップは取りま ょう ● 認証情報や機微な情報はコミット ない

© 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 6

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティとは JIS Q 27000 という情報セキュリティマネジメントシステム(ISMS)関連規格に いて、 情報セキュリティは 情報の機密性、完全性及び可用性を維持 る と。 注記： らに真正性、責任追跡性、否認防止、信頼性などの 　特性を維持 る とも含める ともある。 と定義 れていま 。 7

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 ● 機密性 (Confidentiality) ○ 「認可 れていない個人、エンティティま はプロセスに対 て情報を使用 、ま 開 示 ない特性」 ○ 要はデータ 秘匿 れ守られている と ○ 関連技術：認証・認可、暗号化、など ○ 機密性 担保 れていないとどうなるの ？ ■ 機密情報 流出 て まう ● 完全性 (Integrity) ● 可用性 (Availability) 8

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 ● 機密性 (Confidentiality) ● 完全性 (Integrity) ○ 「正確 及び完全 の特性。」 ○ 要は情報 改竄 れ り消去 れ り に、正確 つ完全に残っている と ○ 関連技術：ハッシュ、署名、メッセージ認証符号、など ○ 完全性 担保 れていないとどうなるの ？ ■ データ 改竄 れて まう ● 可用性 (Availability) 9

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの３要素 ● 機密性 (Confidentiality) ● 完全性 (Integrity) ● 可用性 (Availability) ○ 「認可 れ エンティティ 要求 時にアクセス及び使用 可能である特性」 ○ 関連技術：冗長化、バックアップ、など ○ 可用性 担保 れていないとどうなるの ？ ■ ランサムウェアやDDoSなどの攻撃により、 サービス 停止 情報にアクセスで な なる 10

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの追加の４要素 ● 真正性 (Authenticity) ○ 「エンティティは れ 主張 ると りのものであるという特性」 ○ 真正性 担保 れていないとどうなる ？ ■ なり ま による詐欺 ● 責任追跡性 (Accountability) ○ インシデント発生時、 の影響範囲や経路をエビデンスとともに厳密に特定で るように なっている と ○ Traceability とも ○ 責任追跡性 担保 れていないとどうなる ？ ■ 何 インシデント 発生 際に、「誰 何を 」の 特定 で ない ● 否認防止 (Non-repudiation) ● 信頼性 (Reliability) 11

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 情報セキュリティの追加の４要素 ● 真正性 (Authenticity) ● 責任追跡性 (Accountability) ● 否認防止 (Non-repudiation) ○ 「主張 れ 事象ま は処置の発生、 よび れらをひ エンティティを証明 る 能力」 ○ 否認防止 担保 れていないとどうなる ？ ■ 電子契約をあと ら同意 ていないと否認 れる ● 信頼性 (Reliability) ○ 「意図 る行動と結果と 一貫 ているという特性」 ○ 信頼性 担保 れていないとどうなる ？ ■ データやシステムにヒューマンエラーやバグ あり、システムに不具合 生 る 12

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 攻撃の種類 世の中には様々な攻撃 あり れを知って のも大事で 。 13 不正アクセス ● ネットワーク・ポートスキャン ● パスワードに対 る攻撃 （総当 り・辞書・リスト攻撃など） なりすまし ● マルウェア感染 ● ランサムウェア ● 標的型攻撃 サービス妨害 ● DDoS 脆弱性を狙う攻撃 ● SQLインジェクション ● XSS ● CSRF ● ゼロデイ攻撃・RCE ● OSコマンドインジェクション サプライチェーン攻撃 …

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 多層防御 セキュリティの対策と てよ あるの 入口対策と出口対策で 。 ● 入口対策 ○ も もシステムに侵入 れないように る対策 ○ 具体例：ファイアウォール、WAF、など ● 出口対策 ○ システムに侵入 れて まっ 場合や内部犯の存在を想定 、機密情報の漏洩などを防 めの対策 ○ 具体例：暗号化、EDR、MDM、など 近年、情報システムに対 る攻撃手法は多様化 て り、単一のセキュリティ対策 でサイバー攻 撃を防 のは難 なっていま 。 で現在では様々なレイヤで対策を講 て べ という考え 方 一般的で、多層防御と呼ばれていま 。 入口対策も出口対策も れ以外もで る とはやって ま ょう、という とになりま 。 14

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 ゼロトラスト 従来のセキュリティは境界型で、ネットワークの内側は安全で、外部は危険とみな 、「信頼で る ネットワーク らのアクセスは許可 れ以外は拒否」などと、境界に応 て適宜対策を講 るもの で 。 、昨今では ● 内側であっても、外部 ら一度マルウェア 侵入 て まっ ら攻撃 れるリスク ある ● 従業員による不正のリスクもある ● クラウドやモバイルデバイスを利用 ると境界は曖昧になる といっ 状況で 。 で「内部ネットワーク らのアクセス ら安全」と信頼 るのではな 、何も信頼 常に検 証（認証・認可）を適切に行い安全性を担保 よう、というゼロトラストセキュリティという考え方 広まっていま 。 15

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 セキュリティの対策の他の分類の仕方と て予防的統制と発見的統制 ありま 。 ● 予防的統制 ○ 単に予防とも。英語では Preventative Controls ○ 想定 れる危険なイベント・行動・問題を定義 、 の発生をで る限り予防 るもの ○ ネットワークへの不正アクセスや、意図 ないシステムの変更を防 、第一の防御手段 ○ 具体例 ■ 権限昇格 で ないように る ■ 監査ログはシステム管理者であっても削除で ないように る ■ 削除系など影響 大 いAPIは基本的には使えないように る ■ 特定のリージョン以外でクラウドを利用で ないように設定 る ○ AWS では Organization SCPs という機能を利用 る とで、組織内で予防的統制を設定 る と 可能で 16

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 セキュリティの対策の他の分類の仕方と て予防的統制と発見的統制 ありま 。 ● 発見的統制 ○ 単に発見や検知とも。英語では Detective Controls ○ セキュリティに関わるイベント 発生 際に、 問題の早期検知と記録を行い、進行中のインシデントに 対 て関係者にアラートをあ るような統制 ○ 予防的統制を り抜 セキュリティ問題を ユーザーに通知 る、副次的な防衛手段 ○ 具体例 ■ ルートアカウントの利用や 不正ログインと思われる認証の通知 ■ 影響の大 いAPI 利用 れ 際の通知 17 Finatext での発見的統制のSlack通知のサンプル

© 2024 Finatext Holdings Ltd. 2. セキュリティ一般論 予防的統制・発見的統制 予防的統制と発見的統制は両方とも設定 て べ で 。 ● 予防的統制のみに 場合 ○ 予防的統制の設定ミス あると、 れを り抜 て攻撃 れるリスク ある ○ 対象によっては既存のサービス・仕組みでは実現で ない場合もある ○ 予防的統制は権限を剥奪 る形で実現 る め、強 やり て まうと開発のアジリティ 下 って まっ り る ■ 適用範囲は適宜考える と 大事 ● 発見的統制のみに 場合 ○ 何 重要な事象について早めに気付 る とは良い 、 も も れ 起 ないように 方 安全 18

© 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 22

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 はじめに らはセキュリティで気に べ トピックを細 見てい ま 。 トピック とに以下の内容を紹介 ま 。 ● な やるの ？ ● 対応 る要素 ● 理解 べ 概念 ● リスクの実例 ● 設定例 23

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない ● な ？ ○ インターネットには、不必要に公開 れているポート ら不正にデータを取得 ようと る 仕組み 大量に稼働 ていま 。 ○ HTTPのエンドポイント でな 、MySQLやRedisやMongoDBやElasticsearchといっ データベースに対 ても んな仕組み 動いていま 。 ○ 仮に認証 っていても、認証強度 弱 れば突破 れま 、未適用のパッチによって 稼働 ているサーバーに侵入 れる ともありま 。 ● 対応 る要素：機密性 ● 理解 べ 概念 ○ IPアドレス・ポート ○ ファイアウォールなどネットワークの各種設定 24

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない ● 設定例 ○ security group の設定 ■ ポート番号は必要なものを明示 るように ま ょう ■ ソースはIPアドレスを指定 り、別の security group を指定 るように ま ょう ● 特にインバウンドルールで 0.0.0.0/0 に て まうと インターネット らアクセスで て まう 25 良くない設定例

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ① ポート/コンテンツを不必要にインターネットに公開しない ● 設定例 ○ S3 の “public access block” ■ S3バケットをインターネットに公開 る どう の設定 ■ S3のオブジェクトを直接インターネットに公開 る必要 ないユースケースは多いので 適宜見直 ま ょう ○ RDS の “public accessible” ■ れ オンになると public ip 割り当てられる ■ らに public subnet に配置 れて り、 security group でポート 解放 れていると インターネット らDBにアクセスで るようになって ま ■ 多 の場合 DB を直接インターネットに公開 て 必要はないので、 各種設定を見直 ま ょう 26

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ② 通信時・保存時の暗号化 ● な やるの ？ ○ PC らサーバーまでの経路や、システムへの物理的なアクセスで、 コンテンツを盗聴 れ り改 ん れ り るのを防 め ● 対応 る要素：機密性・完全性 ● 理解 べ 概念 ○ 通信時の暗号化と保存時の暗号化 ■ 暗号化の対象データは、 主に "通信時" と "保存時" に分 て考える と で る。 ■ 通信時の暗号化の技術 TLS等 ■ 保存時の暗号化の技術 FileVault 2等 ○ 通信の経路 ■ ローカルPC らAWSのインスタンスへのアクセス ■ AWSのインスタンス ら外部のAPIを利用 る時の通信 ■ … 27

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ② 通信時・保存時の暗号化 ● 理解 べ 概念 ○ 保存場所 ■ AWS であれば S3 / RDS / EC2 / EBS など ■ ローカルPC ■ … ○ 暗号アルゴリズム ○ 鍵の管理 ○ 暗号化のレイヤー ■ ディスク暗号化 / ファイルシステム暗号化 / ファイルベース暗号化 / カラムレベル暗号化 ... 等 ○ 暗号スイート / Cipher suite ● 設定例 ○ 多岐に渡るので略 28

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 ● な やるの ？ ○ 適切な人・プロセスに適切な権限を与える め ● 対応 る要素：機密性・真正性 ● 理解 べ 概念 ○ 認証と認可 違う と ○ 多要素認証 ○ 長期的・短期的な認証情報 ■ IAM User と IAM Role の使い分 ○ アクセス制御モデル ■ DAC / RBAC / ABAC ● リスクの実例 ○ 弱いパスワードを利用 てい とによる、アカウントの不正利用 29 『AWSの薄い本　IAMのマニアックな話』より

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 ● 設定例 ○ 多要素認証 ■ パスワードによる知識認証とワンタイプパスワードによる所有物認証を組み合わ 、 認証の強度を上 る 30 Step1: 知識認証 Step2: 所有物認証 Google Authenticator などの スマホアプリで生成 れ MFAコードを入力

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ③ 認証・認可 以前の技育CAMPアカデミアで認証認可や最小権限の法則などについて話 ているので 以下の資料も 覧 い！ 31 https://speakerdeck.com/kevinrobot34/introduction-aws-i am-3a810adc-5172-4460-9721-0041456eb2bf

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ④ 最小権限の法則 ● な やるの ？ ○ インシデント 発生 時に攻撃者 で る とを少な て とでリスクを減ら ○ 開発環境で作業 るつもり 本番環境宛にコマンドを実行 て まうといっ ヒューマンエラーを防 ● 対応 る要素：機密性 ● 理解 べ 概念 ○ 定義的な最小性 ■ 実際に利用 る操作の権限 を付与 る、という考え方 ■ 例えばデータの読み込み権限のみ必要な場合には書 込み権限などは付与 ない ○ 時間的な最小性 ■ 強い権限 必要なユースケースもも ろん存在 る 、 の権限 常に必要な とは基本的にない ■ 実際に作業を る間 強い権限を付与 る、という考え方 32

© 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

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ④ 最小権限の法則 TARP など Finatext でのセキュリティについては弊社エンジニアの以下の資料も 覧 い！ 34 https://speakerdeck.com/taiki45/efficient-platform-for-security-and-compliance-89d1ad22-14d6-44df-ab7e-dc4ca7fb470c

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑤ ユーザーアカウントを複数人で共有しない ● な やるの ？ ○ も も多 のサービスに いて利用規約でアカウントの共同利用は禁止 れている ○ アカウント 共有 れているとログの有効性 下 る ■ あるユーザーアカウントのログを見ても「誰」 アクセス の は分 らない ● 対応 る要素：真正性・責任追跡性 ● リスクの実例 ○ Xを複数人で運用 て り、パスワードの管理も杜撰で、不正っぽいアクセス あっ 時に 本当に不正アクセス わ らない ○ あるユーザーアカウントのパスワード 共有 れて り、長期間変更も れて ら 、 退社 メンバーでも利用 ようと思えばで て まう ○ 開発者みんな 使っている共有アカウント 不正利用 れ め、 エンジニア全員の端末をフォレンジック る必要 ありま 、などと 調査範囲 無駄に広 って まう 35

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑥ システム操作のトレーサビリティを確保する ● な やるの ？ ○ インシデント発生時、 の影響範囲や経路をエビデンスとともに厳密に特定 る め ● 対応 る要素：責任追跡性 ● 理解 べ 概念 ○ ログの種類 ■ 接続ログ ■ 認証ログ ■ 操作ログ ■ 変更ログ ■ 通信ログ ■ エラーログ ■ イベントログ ■ アプリケーションログ ■ … 36 https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/centralizing-logs.html

© 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

© 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 ■ データベースは認証ログを含む様々なログを出力で る ■ 用途は れ れ どれも取って と 大事

© 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/

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑦ バックアップを取る ● 設定例 ○ AWS Backup ■ タグを付与 る で簡単にバックアップを取れるように て れるサービス ○ RDS ■ backup：1日１度自動バックアップの設定 可能で、 の保存期間も設定可能 ■ backtrack：指定 時間までDBクラスターを巻 戻 る機能 40

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 ⑧ 認証情報や機微な情報はコミットしない ● な やるの ？ ○ パスワードや秘密鍵、APIキーなどに紐づ 権限を悪用 れるのを防 め ○ Jupyter Notebook などで分析 てい 機微なデータ 漏洩 るのを防 め ● 対応 る要素：機密性・真正性 ● リスクの実例 ○ Qiita - GitHub に AWS キーペアを上 ると抜 れるってほんと？？？試 てみよー！ の記 事によると、AWSのアクセスキーを public repo に push ると13分で悪用 れ との と ● 設定例 ○ gitleaks や git-secrets といっ ツールを導入 、pre-commit の hook を設定 る とで コミット前に認証情報や機微な情報 含まれない を確認 、含まれ うな場合にはコミッ ト で ないように る ○ 鍵のファイルや環境変数を設定 るファイルは .gitignore に設定 て 41

© 2024 Finatext Holdings Ltd. 3. セキュリティ各論 まとめ ● セキュリティの一般論を整理 ま ○ セキュリティとは機密性・完全性・可用性を担保 る とで ○ 多様な攻撃、多層防御、ゼロトラスト、予防的統制・発見的統制といっ セキュリティで重 要となる考え方を確認 ま ● クラウドでセキュアに開発 る際の様々なトピックを確認 ま ○ ポート/コンテンツを不必要にインターネットに公開 ないように ま ょう ○ 暗号化、認証・認可、ログの取得、バックアップの取得は っ りやりま ょう ● セキュリティは幅広い技術領域 関係 、非常に難 いで 、 一般論と個別の具体的な論点と両面 ら学習 てい とで、徐々に理解 深まるは で ○ 継続的に振り返り、セキュリティを意識 て開発で るエンジニアになりま ょう！ 42

© 2024 Finatext Holdings Ltd. アジェンダ 1. イントロダクション 2. セキュリティ一般論 3. セキュリティ各論 4. Appendix 43

© 2024 Finatext Holdings Ltd. 4. Appendix 参考書籍 ● 『図解即戦力 暗号と認証の みと理論 っ りわ る教科書』 成 滋生 ● 『暗号技術入門 第3版　秘密の国のアリス』 結城 浩 ● 『AWSの薄い本　IAMのマニアックな話』 佐々木拓郎 ● 『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』　徳丸 浩 ● 『イラスト図解式 の一冊で全部わ るネットワークの基本 第2版』 福永 勇二 44

© 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

No content