FinOps と GDPR から始めた Memolog のセキュリティ改善
Memolog は個人サイトです。最初から企業向けのセキュリティ構成を目指していたわけではありません。
きっかけは、Azure の費用を把握する FinOps、海外からのアクセスも考えた GDPR とプライバシー対応、Application Insights のデータをどこまで収集するか、といった別々の疑問でした。そこから実際のアクセスや攻撃面を調べるうちに、Front Door、WAF、Azure Policy、Microsoft Sentinel、DNSSEC、セキュリティ演習までつながりました。
特に驚いたのは、Azure Front Door のレポートで世界中からアクセスされている様子を見たことです。自分では日本語中心の小さなサイトだと思っていても、公開した瞬間からインターネット全体へ接続されています。
この記事では、個別の Azure サービスを並べるのではなく、どのような疑問から始まり、何を観測し、どう脅威を整理し、どのルールと運用へ落としたかを振り返ります。
目次
- 先に結論
- 出発点は FinOps とプライバシーだった
- Front Door で見えていなかったアクセスに気づいた
- OWASP と実例から攻撃面を見直した
- STRIDE で製品ではなく脅威から整理した
- Azure Policy は止める前に Audit で学べる
- 現在の構成は防御と証跡を分けている
- 実装だけでなく演習で確かめる
- 個人サイトで取り組んで分かったこと
- まとめ
- 参考資料
先に結論
今回の取り組みで一番大きかった学びは、セキュリティはサービスを追加する作業ではなく、次の循環を作ることだという点です。
- 目的を決める: 守るデータ、許容する費用、法令や運用上の制約を整理する
- 観測する: Front Door、Application Insights、Log Analytics で実際の通信と変更を見る
- 脅威を整理する: OWASP、STRIDE、実際の攻撃事例から信頼境界と攻撃経路を洗い出す
- 統制する: WAF、Managed Identity、Azure Policy、DNSSEC、CI の権限境界へ落とす
- 演習する: Sentinel の incident や tabletop で、検知と復旧が本当に使えるか確かめる
- 残ったリスクを追跡する: 未実証のものを「対応済み」にせず、owner と期限を決める
Azure Well-Architected Framework には、Security だけでなく、Reliability、Cost Optimization、Operational Excellence、Performance Efficiency があります。Memolog でも、WAF を強くすれば費用とログ量が増え、ログを減らせば調査能力が下がります。1 つの柱だけを最大化するのではなく、サイトの規模と守るものに合わせてバランスを取る必要がありました。
出発点は FinOps とプライバシーだった
最初に取り組んだのは、攻撃対策ではなく費用とデータの把握でした。
FinOps から始めた理由
Azure は小さく始められますが、ログ、リクエスト、Functions の実行、Storage transaction も利用量に応じて費用になります。セキュリティ機能にも、Front Door Premium、Log Analytics、Sentinel、Defender for Cloud などの費用があります。
一方で、費用を下げるためにログを短くする、監視を外す、冗長性を下げると、調査や復旧が難しくなります。Azure Well-Architected Framework の Cost Optimization と Security の trade-offでも、セキュリティ対策の費用と侵害時の影響を比較し、合意したリスク水準より下まで対策を削らないことが示されています。
Memolog では、すべてを最大構成にするのではなく、次のように役割を分けました。
| 対象 | 方針 |
|---|---|
| 日常の Application Insights / 運用ログ | 30日保持、0.1 GB / 日の上限を設定 |
| Front Door access / WAF log | 専用 Log Analytics に90日保持し、日次上限を設けない |
| 長期のセキュリティ証跡 | ZRS Storage に365日保存 |
| Hot Topics / ViewCounts | ZRS を使用し、リージョン障害時は再構築・再収集を基本とする |
| 高額なセキュリティ機能 | 実際のリスクと費用を確認して個別に判断する |
これは「安くする」だけではありません。費用の上限を決めながら、止めてはいけない証跡は別経路へ逃がす設計です。
GDPR と同意管理から見えたこと
Application Insights のブラウザー SDK は、匿名 ID、session、browser 情報などを扱います。公開する閲覧数が集計値だけでも、その前段にある telemetry まで自動的に「個人データではない」とは言えません。
そこで、分析へ同意した後だけ SDK を読み込み、拒否時と撤回後は送信しないようにしました。参照元は完全な URL ではなく hostname だけ、campaign parameter も許可した3キーと制限済みの値だけを送ります。公開する閲覧数 snapshot には、生の user ID、session ID、IP、地域情報を含めません。
GDPR 対応を考えたことで、収集前の同意だけでなく、目的、保存期間、アクセス権、削除、外部委託、障害時の証跡まで考えるようになりました。プライバシーとセキュリティは別の作業ではなく、どのデータを、なぜ、どこへ、いつまで保存するかという同じ設計につながっています。
Front Door で見えていなかったアクセスに気づいた
Azure Front Door Premium と WAF を導入して印象が変わったのは、サイトの入口で起きていることが見えるようになった点です。
Azure portal の Front Door レポートでは、北米、南米、ヨーロッパ、中東、アジア、オセアニアなど、多くの地点からリクエストが届いていました。日本語中心の個人サイトでも、検索 engine、正規の crawler、未知の Bot、脆弱性を探す自動 scan、通常の閲覧者が国境に関係なく到達します。
ただし、地図上の点をすべて「攻撃者」と考えるのは正確ではありません。
| 情報 | 分かること | そのまま断定できないこと |
|---|---|---|
| Front Door access log | Front Door を通った request、応答、cache、client IP 由来の地域など | 人か Bot か、善意か悪意か |
| WAF log | WAF rule に一致した request、rule、action | 一致が真の攻撃か false positive か |
| Bot Manager | good bot、bad bot、unknown bot の rule 分類と action | unknown bot の最終的な意図 |
| Application Insights | 同意後の page view と application telemetry | 同意前を含む全 HTTP request |
Azure Front Door の公式監視資料では、access log は Front Door を通る request を記録し、WAF log は潜在的な攻撃や false positive の調査に使うと説明されています。また、access / WAF log は既定では有効ではなく、Diagnostic settings で明示的に保存先を構成する必要があります。
Premium で利用できる Bot Manager は、bad bot を block、good bot を allow、unknown bot を log する既定 action を持ちます。Memolog では WAF を Prevention mode にしているため、rule に一致した request は設定した action に従って edge で処理されます。
つまり、Premium にしただけで世界中のアクセスが発生したのではありません。以前から到達していた通信を、Front Door のレポート、WAF、Bot rule、Log Analytics で観測し、分類できるようになったと考えるのが正確です。
OWASP と実例から攻撃面を見直した
WAF の managed rule を有効にすると、SQL injection や cross-site scripting のような有名な攻撃を意識しやすくなります。Azure Front Door WAF の Default Rule Set は OWASP Core Rule Set を基礎にし、Microsoft Threat Intelligence の rule も含みます。
ただし、Memolog の攻撃面レビューで最も優先度が高かったのは、典型的な SQL injection ではありませんでした。
Hot Topics の匿名検索 API は、当初、検索や存在しない article ID の確認で複数 partition を走査する可能性がありました。攻撃者が高コストな request を繰り返すと、Functions の実行時間、scale-out、Storage transaction、telemetry が増えます。データを盗まなくても、計算量とクラウド費用を攻撃対象にできるということです。
そこで、次の対策を行いました。
- 検索用 index を事前生成し、request ごとの全件走査をやめる
- article 取得を PartitionKey / RowKey の point read にする
- query、body、配列、文字列へ上限を設ける
- feed 由来 URL を
https:と既知 hostname に限定する - rate limit と distributed low-rate API traffic の検知を追加する
- origin への直接アクセスを制限し、Front Door 経由に集約する
- 公開する必要がない status detail と管理 operation を外へ出さない
さらに、credential leakage や管理者 lockout の事例から、「通常時の防御」だけでなく、「漏れたと仮定したときの revoke」「MFA device を失ったときの復旧」「監視基盤自身が止まったときの通知」を考えました。
実例を脅威モデルへ取り込むと、チェックリストには出にくい運用上の穴を見つけられます。
STRIDE で製品ではなく脅威から整理した
対策が増えると、「Front Door を入れた」「Sentinel を有効にした」という製品一覧になりがちです。そこで、Memolog では STRIDE で asset、entry point、trust boundary、owner、残余 risk を整理しました。
| 分類 | Memolog で考えた例 | 主な control |
|---|---|---|
| Spoofing | 別 repository / branch から deployment identity を使う | GitHub OIDC の issuer / audience / main subject |
| Tampering | workflow、Bicep、security log を改ざんする | immutable Action SHA、Git history、独立 archive |
| Repudiation | 管理変更の実行者や理由を否認する | GitHub Issue、Activity Log、Sentinel incident |
| Information Disclosure | telemetry、secret、raw log が漏れる | consent gating、masking、Managed Identity、log hygiene |
| Denial of Service | API の高コスト処理、distributed L7、daily cap 到達 | WAF、rate limit、query 改善、独立 security workspace |
| Elevation of Privilege | runtime / deployment identity の過剰権限から横展開する | identity 分離、resource scope の RBAC、定期 audit |
この整理で重要だったのは、control を書くだけでなく、残っている risk と owner を書いたことです。
たとえば archive Storage は365日保持しますが、immutability はまだ有効にしていません。書き込み、lifecycle deletion、recovery を検証する前に固定すると、運用を壊す可能性があるためです。「機能があるから使う」ではなく、保護効果と復旧への影響を確認してから判断します。
Azure Policy は止める前に Audit で学べる
Azure Policy には、企業が使える region や SKU を制限する仕組み、という印象を持っていました。実際には、組織のルールを Azure resource へ継続的に照合し、逸脱を見つける用途にも使えます。
代表的な effect は次のように異なります。
| Effect | 動作 | 導入時の使い分け |
|---|---|---|
Audit | request を止めず、Activity Log に warning を作り、resource を non-compliant として示す | 影響と例外を把握する最初の段階 |
Deny | 条件に合わない create / update を拒否する | 十分に検証した安定した guardrail |
Modify | tag など request の一部を変更する | 自動補正が安全な項目 |
DeployIfNotExists | 必要な関連 resource や設定を deploy する | diagnostic settings などの標準化 |
Azure Policy の custom policy tutorialでも、Deny にする前に policy の影響を確認するため、Audit は良い最初の選択肢とされています。
Memolog では、次のような baseline を Audit で割り当てました。
- public network access が無効か
- Storage の shared key authorization を使っていないか
- secure transfer が必要になっているか
- diagnostic settings が構成されているか
- Managed Identity や private endpoint が必要な resource にあるか
- environment、owner、cost などの tag があるか
最初からすべてを Deny にすると、既存 resource の更新や緊急時の復旧を想定外に止める可能性があります。まず compliance state を見て false positive と例外を整理し、必要性と rollback が確認できた rule だけを強制へ進める方が安全です。
Policy は「利用者を縛るもの」だけではなく、自分たちで決めた設計原則が時間とともに崩れていないかを確認する自動レビューとして使えます。
現在の構成は防御と証跡を分けている
2026年8月26日時点の主な構成を、公開経路、data plane、security evidence、control plane に分けると次のようになります。
公開経路
www.memobog.netは Azure Front Door Premium を入口にする- WAF は Prevention mode で、managed rule、Bot rule、custom rate limit を使う
- 静的 page は Azure Static Web Apps、
/api/*は Azure Functions へ route する - Function origin は
AzureFrontDoor.Backendservice tag とx-azure-fdidで Front Door 経由に制限する - public management API と
/adminは廃止し、退役 route は404を返す
Data と identity
- Hot Topics と ViewCounts は public network access と shared key を無効にした ZRS Storage に保存する
- Functions は Private Endpoint 経由で Storage へ接続し、Managed Identity と resource scope の RBAC を使う
- 収集、翻訳、閲覧数同期、archive recovery は Timer trigger へ移し、外部から管理 operation を呼ばない
- GitHub Actions は UAMI へ OIDC で login し、長期 client secret を持たない
- Pull Request job は Azure login と repository secret を使わない
観測と security evidence
- Application Insights と運用 Log Analytics は日常の performance と failure を見る
- Front Door access / WAF log は専用 security Log Analytics と archive Storage へ同時配送する
- Microsoft Sentinel は9個の analytics rule と4個の automation rule で incident を作成・分類する
- Defender for Cloud、Activity Log、Azure Policy compliance を構成変更と posture の確認に使う
DNS と supply chain
- Azure DNS zone signing と親
.netの DS record で DNSSEC trust chain を構成する - CAA で certificate issuer を DigiCert に限定する
- registrar の transfer lock と二段階認証を有効にする
- GitHub Actions は job 単位の permission と full commit SHA で固定した Action を使う
- deployment credential の棚卸しでは、workflow 参照がなくなった
BACKFILL_TOKENSecret も削除する
境界の考え方は、すべてを 1 つの workspace や identity へ集約しないことです。application が侵害された場合にも security evidence を同じ権限で消せないようにし、deployment identity、runtime identity、人の admin identity を分けています。
実装だけでなく演習で確かめる
構成図に線が描かれていても、incident が作られ、担当者へ割り当てられ、調査して閉じられるとは限りません。
Memolog では、controlled distributed L7 exercise を実施し、Sentinel で次を確認しました。
- incident が作成される
- owner が自動設定される
prodとdistributed-l7label が付く- client IP、URI、origin 到達、429、送信元ごとの peak を調査できる
- 自動遮断は行わず、確認後に
BenignPositiveで閉じられる
また、次の 3 シナリオを tabletop で確認しました。
| Scenario | 確認した判断 | 残った課題 |
|---|---|---|
| SWA deployment token leakage | 調査より revoke を優先し、旧 token へ戻さない | 実際の rotation と production recovery は未実証 |
| Monitoring loss / daily cap | capped workspace と独立 security destination を識別する | 欠測した監視に依存しない自動通知は未実証 |
| Administrator lockout | MFA / Conditional Access を全体無効化せず、Azure、GitHub、registrar を分けて復旧する | tested recovery path と実 RTO は未実証 |
Azure の incident response guidanceは、準備、検知と分析、封じ込めと復旧、事後活動という NIST SP 800-61 の段階に沿っています。tabletop は実際の復旧時間を証明しませんが、事故が起きる前に判断順序、stop condition、rollback、owner、必要な証跡を確認できます。
「設定した」と「使える」は別です。Memolog では、未実証の rotation、独立 monitoring signal、administrator recovery を期限付き Issue として残しています。
個人サイトで取り組んで分かったこと
小さなサイトでも公開面は小さくない
利用者が少なくても、公開 hostname と API は crawler や automated scan から見えます。page view が少ないことと、HTTP request や攻撃試行が少ないことは同じではありません。
セキュリティと FinOps は対立ではなく設計条件
ログを無制限に集めればよいわけでも、費用のために全部切ればよいわけでもありません。investigation に必要な log を別 workspace と archive に分け、日常 telemetry には cap を置くように、用途ごとに費用と保持を決められます。
Policy は組織規模に関係なく役立つ
Azure Policy は大企業だけのものではありません。1人で運用していても、数か月後の自分が同じ設計原則を覚えているとは限りません。Audit で drift を見つけるだけでも価値があります。
管理 API を強く守るより、なくせるかを考える
認証方式を複雑にする前に、その operation を Internet へ公開する必要があるかを見直しました。定期処理にできるものは Timer trigger と Managed Identity へ移し、公開 entry point 自体を減らしました。
脅威モデルは完成品ではない
新しい API、identity、secret、data store、external integration を追加すると trust boundary が変わります。重大な incident や exercise failure の後にも、STRIDE と runbook を更新する必要があります。
まとめ
Memolog のセキュリティ改善は、WAF を入れるところから始まったわけではありません。
Azure の費用を理解したいという FinOps の関心、海外利用も考えた GDPR と privacy、Application Insights のデータをどこまで集めるかという疑問が出発点でした。Front Door を導入して世界中から request が届く現実を観測し、OWASP と実例から API のコスト攻撃や credential leakage を考え、STRIDE で trust boundary と owner を整理しました。
その結果を WAF、Managed Identity、OIDC、Azure Policy の Audit、独立した security log、Sentinel、DNSSEC、管理 API 廃止へ落とし、最後に controlled exercise と tabletop で使えるかを確認しています。
完成したわけではありません。未実証の recovery path や monitoring signal も残っています。それでも、観測し、脅威を言語化し、ルールへ落とし、演習し、残課題を追跡する循環ができたことで、次の変更をどの視点で評価すべきかが分かるようになりました。
個人サイトでも、最初からすべての製品を導入する必要はありません。まず、何を収集し、何を守り、どの risk と費用を受け入れるかを決めます。そのうえで入口の log を有効にし、実際の traffic と変更を観測するところから始めると、必要な対策を具体的に選びやすくなります。
参考資料
- What is the Azure Well-Architected Framework?
- Monitor Azure Front Door
- Azure Web Application Firewall on Azure Front Door
- Azure Policy definitions audit effect
- Tutorial: Create a custom policy definition
- Incident response overview for Azure
- Azure Front Door Standard と Premium の違いを整理する
- GitHub Copilot を活用した Azure インフラ設計の方法
- AWS FinOps Agent から考える Azure の FinOps AI の選び方