クラウドの“設定ミス”に注意しよう？
世の中のクラウドセキュリティベンダーは、「クラウドの“設定ミス”が大きな情報漏えいにつながる。だから、セキュリティ製品でアラートをあげて未然に防ぎましょう」というメッセージを打ち出している。この製品とは、CSPM（Cloud Security Posture Management）というカテゴリの機能を提供するものを指す。Gartner（ガートナー）が名付けた名称だ。
筆者は、このセールスメッセージである「設定ミス」という表現が適切ではないと考えている。その理由は、“Posture（ポスチャー）”の訳の解釈にある。
一般的に、Postureには「態勢、姿勢」などの意味があるが、ITの世界では「構成（状態）」の意味になる。“Configuration（構成）”とイコールだ。これを「設定」と訳してしまうことで、「悪い設定＝設定ミス」という解釈になってしまっているのではないだろうか（設定とは、一般的には“Setting”である）。
つまり「設定ミス」ではなく、正しくは「構成ミス（または構成の不一致）」と表現すべきである。
ここでいう「構成」とは何か、そのためには構成アイテム（Configuration Item）を知ることが近道だ。構成アイテムとは、一般的な情報システム向けに言えば、ハードウェア（サーバ、ルータ、スイッチ、端末など）、ソフトウェア（OS、アプリ、ミドルウェア、バージョン構成など）、設計書、構成図、契約書、メールサービス、Webアプリケーション、仮想リソース、設定値（ACL、ポリシー、スクリプトなど）が当てはまる。
本稿ではクラウドサービスが対象であるため、PaaS/IaaSを例にとると、仮想マシンの設定、サイズ、OSバージョン、Dockerイメージ、Kubernetes Pod、ECSタスク、VPC/サブネット/仮想ネットワーク、セキュリティグループ/ネットワークセキュリティグループ、ルートテーブル/インターネットゲートウェイ、IAMユーザー/ロール/ポリシー、アクセスキー、APIトークン、フェデレーション設定、オブジェクトストレージ、ブロックストレージ、ファイルストレージ、監視項目、ログ保存設定、障害発生時の通知先、チャネル構成、WAFルールや暗号鍵、セキュリティポリシーなどのセキュリティ設定が該当する。
これらが、ユーザーが期待する正しい構成の状態に保たれていることを実現するのが「構成管理（Configuration/Posture Management）」である。
構成管理に関するガイドラインには様々なものがあるが、ここでは開発者・運用者向けのDevOpsに最適なセキュリティを重視したガイドラインである、米国の『NIST SP 800-128』を参考に、下記でどのような要素に重点が置かれているのか見てみよう。
- 識別：サービス構成アイテム（CI：Configuration Item）の識別と管理
- 制御：構成管理の管理プロセスを整備し、変更が必要な場合に適切に実施する
- 監視と報告：構成管理プロセスが正常に機能しているか監視し、定期的に報告する
- バージョン管理：CIの変更履歴を管理し、過去の状態に戻せるようにする
この「構成管理を徹底する」というのは、ユーザーが自らの期待した状態（=Posture）になっているかを定期的に確認する仕組みをプロセス化し、実行していくことである。つまり、設定（＝Setting）を確認するだけでは不完全であり、ユーザーが期待する構成（セキュアで正しい状態）になっているかどうかまでチェックすることが、ユーザーの責務になっているということだ。
もし設定を確認するだけで、その後、意図しない状態のまま運用されているのであれば、それはユーザーの瑕疵（かし）とみなされてしまう。設定ミスだけでなく、正しい構成の状態か否かまでを常に確認することが極めて重要であると理解すべきだ。
さて、ここでCSPMが注目を浴びている背景を見ていこう。こうしたジャンルの製品の必要性が訴えられるきっかけとなったのは、あるセキュリティ侵害事例からである。2020年12月17日、金融庁が『Salesforceの製品の設定不備による意図しない情報が外部から参照される可能性について』と題した注意喚起を促し、当該事象を引き起こす複数の条件を満たす金融機関は、速やかに財務局に報告するよう指示を行った。現在は、金融庁の当該注意喚起のサイトは見つからないため、同様の事象でその後、NISC（内閣サイバーセキュリティセンター）が注意喚起した掲載リンクを以下に記載する。
NISC『Salesforceの製品の設定不備による意図しない情報が外部から参照される可能性について』（2021年1月29日）
本件は、Salesforceの製品においてデータのアクセス権などの設定不備により、意図しない情報が外部から参照可能になってしまうという事象が発生したことを受けての注意喚起である。過去の記事から推測すると、2016年にSalesforceがUIの改善、効率化機能のエンハンスを目的に行った改変がきっかけのようだ。その結果、ゲストユーザーがオブジェクトにアクセスできるという仕様がデフォルトで有効になっていたのだという。
この後、米Salesforce, Inc.は、本事象に関する注意喚起を顧客に対して何度か行っていた。また、これに起因して2020年末に楽天やPayPayで顧客情報の流出が発覚している。Salesforceからの注意喚起メッセージを把握できておらず、設定を変更できていなかったのが原因のようだ。
Salesforceだけではない。Amazon Web Services（以下、AWS）でも、2017年7月に似たような事例が発生している。これを受けてAWSは、一部の顧客に対しメールで「Amazon S3におけるバケットポリシーやアクセスコントロールリスト（ACL）の設定不備によって、同サービス上の重要なデータが漏えいするセキュリティリスク」に対する注意喚起を送信し、設定の見直しを呼び掛けている。
