セキュリティ対策はじめました。​ ～やったこと紹介～​

2023/11/28　JAZUG Night#45での資料。

Transcript

1. セキュリティ対策はじめました。 ～やったこと紹介～ 第45回 Tokyo Jazug Night 2023/11/28 hikari
2. 自己紹介  名前：影中 光（かげなか ひかり）  仕事：要件定義、インフラ、スクラムマスター  経歴：  新卒入社～4年目：オンプレミスのインフラエンジニア。  5～9年目(現在)：自社製品のWebサービス開発。  X(旧Twitter)：@_mi_lin_
3. 今日話すこと  2023/03~現在にかけて、自社製品のインフラ周り・開発環境周りのセキュリティ面を中心に改善活動し ました。  基本的にやったことのお話です。アーキテクチャの設計などの話はあまりできません。  1人の詳しい人の設計をもとに推進しました。経験の浅いメンバーにどうやって方針を展開して取り組ん だのか等、体験談的なところも少し話します。
4. アジェンダ  問題点  主に実施したこと  その他やったこと  次にやりたいこと
5. 問題点
6. 問題点 システムの問題 • ソースコードの問題 • ネイティブアプリのようなもの • 納期を優先したもの • 自動化は全くない • セキュリティ対策が考慮しきれていないク ラウドインフラ • 分業で作られた数の多いシステム 人財の問題 • 内製ができていない • モダンな開発経験のない若手 • クラウド開発経験者がいない
7. イメージ エンドユーザー API (Web App) SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア
8. イメージ エンドユーザー API (Web App) SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア できるところからセキュリティ対策しよう！
9. やったこと4つ 1. SQLへの認証変更：マネージドID 2. 構成情報の分離：Key Vault 3. ログの出力：Application Insights 4. CI/CD化(デプロイ方法の改善)：Azure DevOps
10. 1.SQLへの認証変更
11. Before After すべてSQL認証 1.SQLデータベースへのアクセスは開発者もシ ステムもすべて従来のSQL認証 用途に応じて認証方法を分ける 1.開発者はMicrosoft Entra ID認証 2.システム共通DBへのマネージドID認証 3.各システム固有のDBへのアクセスは従来の SQL認証 適切な権限分けができていない 1.とりあえずアクセスできれば良いとして、過剰な権 限付与している 2.リソースごとユーザーごとにアクセス許可を設定 している 権限設定の見直し 1.ユーザーとシステムを用途ごとにグルーピング 2.グループごとに権限を設定
12. イメージ エンドユーザー API (Web App) SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア マネージドID SQL Server 認証
13. マネージドID  機能  アプリケーションに必要な資格情報をMicrosoft Entra ID 認証にできる  種類  システム割り当てとユーザー割り当て プロパティ システム割り当て ユーザー割り当て 作成 Azure リソースの一部として作成される。 スタンドアロンの Azure リソースとして作成される。 削除 親になるAzure リソースが削除されると、マネージド ID も削除される。 明示的に削除する必要がある。 Azure リソース 間の共有 共有できない。 1 つの Azure リソースにのみ関連付けることができる。 共有できる。 同じユーザー割り当てマネージド ID を、複数の Azure リソースに関連付けることができる。 一般的なユース ケース 1 つの Azure リソース内にIDが含まれる場合。 独立した ID を必要としている場合。 1 つの仮想マシンで実行されるアプリケーションの場合。 複数のリソースで実行され、1 つの ID を共有する場合。 リソースが頻繁にリサイクルされるものの、アクセス許可は一貫性を保つ必要がある場合。 複数の仮想マシンが同じリソースにアクセスする必要がある場合。
14. やったこと
15. 権限のグルーピング  DBにアクセスする人と各システムをMicrosoft Entra IDでグルーピングする  グループごとにAzureロールの割り当てをする 区分 グループ 対象者 権限 ユーザー Admin 開発責任者 すべてのリソースにR/W可能 Developers 開発チームの社員 開発環境のリソースのみR/W可能 Operators 運用チームの社員 特定のリソースのRのみ可能 PartnerDevelopers 開発チームの協力会社 開発環境のリソースのRのみ可能 システム AdminApps 社員が使うシステム すべてのDBにR/W可能 UserApps ユーザーが使うシステム 契約している範囲のDBにのみR/W可能
16. SQL Serverの設定  管理者の設定  SQL Server>Microsoft Entra ID>管理 者設定>管理者グループを設定  監査の設定  SQL Server>監査>AzureSQL監査設定  ストレージ認証の種類をマネージドIDに する。
17. Web Appsの設定  Web AppsにマネージドIDを有効にする  Web Apps>ID>システム割り当て済み  az webapp identity assign  SQLへの接続文字列をマネージドID用に変更  Authentication=Active Directory Managed Identity;
18. 大変だったこと
19. 大変だったこと  誰にどこまでの権限を与えるかを決めること  各システムがどのDBを参照しているか把握すること  たまにしか触らない人が今更なタイミングでDBにアクセスできないと言ってくること
20. 2.構成情報の分離
21. Before After 情報のハードコーディング 1.シークレット情報 2.環境固有の設定 情報の分離 1.ソースコード内にシークレット情報、環 境固有情報がない状態 2.Web Appsの構成情報から取得する 手動での情報管理 1.値の管理は手動 2.人の目に触れやすい Key Vaultでの情報管理 1.値の管理はAzureにおまかせ 2.権限による閲覧制限
22. イメージ エンドユーザー API (Web App) SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア Key Vault
23. Key Vault  Azure の主要な管理ソリューションの 1 つ  シークレットの管理  トークン、パスワード、証明書、API キー、その他のシークレットを安全に格納  キー管理  データの暗号化に使用される暗号化キーの作成と制御。  証明書の管理  TLS/SSL 証明書のプロビジョニング、管理、デプロイ
24. やったこと
25. 対象の洗い出し  分離対象を洗い出して一覧にする。  それぞれの情報に対して何をするのか記載  変更後の値の記載 対象システム 既存キーの種類 既存キーの値 キーに対して実施 する内容 Key Vaultの値 システムA ハードコーディング abc appsettings.jsonか ら固有の文字列を 空白する。 システムA-Key システムB 接続文字列 123 接続文字列をユー ザーシークレットに 設定する。 システムB-Key
26. Key Vaultの設定  キーコンテナーリソースの作成  bicepで作成  リソースへの権限設定  シークレット情報の登録  az Key Vault secret set
27. Web Appsの設定  構成の設定  シークレット情報の登録。  値はKey Vaultを参照するように設定。  マネージドIDを許可する  SQLへの認証変更で実施  キーコンテナのアクセス権を付与するため
28. ソースコードの修正  ハードコーディングされているシークレット情報、環境固有情報を取り除く。  Web Appsの構成情報から値を読み取るように修正。
29. 大変だったこと
30. 大変だったこと  やることの目的と実施内容をチーム内共有するところ。  対象のシークレット情報を洗い出すのが大変だった。  なぜ隠さないといけない情報なのかの理解から始めないといけなかった。この理解が不十分なためにあとから ぽろぽろ抜け漏れが出たりした。  たまにKey Vaultの認証が外れる。  Web Apps のKey Vaultリファレンス+VNETは起動時に時間がかかるので、タイムアウトしていた。  推奨値に合わせると費用が倍になってしまうため、すぐの対応が難しい。
31. 3.ログの出力
32. 改善前 エラー発生時のフロー
33. 改善後 エラー発生時のフロー
34. イメージ エンドユーザー SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア ログ・アラート API (Web App)
35. Application Insights  Azure Monitor の拡張機能の一つ  アプリケーションのパフォーマンスを管理できる Azureのサービス  機能  ログの保存。  アプリのパフォーマンス監視ができる。  アプリケーションマップでアプリケーション同士の依 存関係を可視化できる。  アラートが起きた時にどうするのかのルール設定が できる。  データの検索はKustoクエリ言語（KQL)
36. やったこと
37. Application Insightsの設定  リソースの作成  bicepで作成。  通知設定  アラートルール＞編集＞アクショングループの編 集＞logic apps指定
38. Web Appsの設定  Web Appsの構成にApplication Insightsの接 続文字列を設定する
39. ソースコードにログ出力の記載を追加  ログに出力する項目をルール決め  必須で出力するもの  ユーザーを特定できる識別子  システムを特定できる識別子  機能を特定できる識別子  イベントの詳細内容  シークレットや機密情報に関する情報は対象外  ログレベル APIのリクエスト、レスポンス、外部サービスの実行と結果に関しましては、Information 例外とはならなくとも通常のフローでは考えられない値の場合、もしくは継続して処理を 行っている例外の場合はWarning 例外により処理を中断して即時結果を返す場合はError  作業の進め方  ログに関する変更の見本を共有する。見本を元にまず一人がオペレーターになってモブでやってみる。
40. 大変だったこと
41. 大変だったこと  ログ出力箇所が多い  ログ出力の対象の決め方が難しかった  ログの見方(Kusto)  対策として、テンプレートを用意した  受け取ったアラートの運用ルールが決まらない
42. 4.CI/CD化(デプロイ方法の改善)
43. 改善前デプロイ手順 最新のソースコー ドをローカルに落 としてくる ローカルにリモー トブランチを設定 する リモートブランチに 向けてコマンドで プッシュする git push prod main:master Web Appsにデプ ロイされる 本番環境にアクセス権のある開発責任者しかできない
44. 改善後デプロイ手順 最新のソースコー ドをローカルに落 としてくる mainのブランチに プッシュする Web Appsのス テージングスロット にデプロイされる スワップボタンを 押下する 本番環境にアクセス権がなくてもできる 本番環境にアクセス権 がある人だけができる
45. Before エンドユーザー SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア Azure DevOps Pipelines API (Web App)
46. Azure DevOps Pipelines  Azure DevOpsの中のCI/CD機能。ソースコードのビルド、テスト、デプロイができる。  主な機能  Pipelines：CI/CD機能  Environments：デプロイの履歴管理  Releases：自動デプロイ機能  Library：変数の定義  Task groups：複数プロジェクトを管理するための一括設定機能  Deployment groups：仮想マシンのグループ
47. やったこと
48. Azure Web Appsの設定  ステージングスロットの作成  Web Apps>デプロイ スロット>スロットの追加  ステージングスロットと本番稼働スロットの2スロット
49. ソースコードの変更  フォルダ構成の変更  Pipelines用の新規フォルダ作成  Pipelinesフォルダに合わせて、既存のフォルダの 階層を変更  ソースコードにYAMLファイルを追加する  Pipelinesで実行する内容を記載。  masterブランチをmainブランチにする  ブランチ戦略の変更
50. Azure DevOpsのPipelines  Service Connectionを作成する  DevOpsとAzureリソースをつなぐためのインターフェイス  Azure DevOps>Project Settings>Service connections>Create service connection>Azure Resource Manager>Workload Identity federation(automatic)>サブスクリプション指定  Pipelinesを作成する  Pipelines>New pipeline>Azure Repos Git>リポジトリ選択>Existing Azure Pipelines YAML file>ブランチとYAMLファイ ル選択>Review>Run  YAMLの中に書かれていることが実行される。  Tips：YAMLファイルの書き方  Azure DevOps上にはYAMLを書くためのアシスタント機能がある。  https://learn.microsoft.com/ja-jp/azure/devops/pipelines/get-started/yaml-pipeline-editor?view=azure-devops
51. 大変だったこと  YAMLに不慣れ  どのタイミングでどこまで実施されるのかの把握  Service Connectionを作る時のAzureのサブスクリプションを選択にて、「+New Azure Subscription」をク リックするとステージングページに飛ぶ。  URLの「staging」の文字を消すと正常なページに飛ぶ。
52. その他にやったこと
53. その他やったこと  態勢管理： Microsoft Defender for Cloud の導入  Virtual Networkの導入  メンテナンスサイトの実装  内製化
54. BeforeAfterまとめ
55. Before エンドユーザー API (Web App) SQL DB 静的Webサイト (Blob) CDN フロントエンドエンジニア バックエンドエンジニア
56. After フロントエンドエンジニア エンドユーザー 静的Webサイト (Blob) SQL DB CDN ログ・アラート 診断・監査データ (Blob) Key Vault VNet VNet Microsoft Defender for Cloud アクセス制御 マネージドID SQL Server 認証 バックエンドエンジニア Azure DevOps Pipelines API (Web App)
57. 次にやりたいこと
58. 次にやりたいこと  ログ出力の精査  CI/CDの続き：UIのデプロイ手順改善。テスト自動化導入。  WAFの導入：着手中  メールサーバーの移行
59. ご清聴ありがとうございました。