なぜ設定ミスはなくならず、攻撃され続けるのか？
「クラウドの攻略は設定ミスを探すところから始めると良い」
dockleを用いてCVE以外の致命的なセキュリティホール対策の記事でも述べましたが、ハッカーが利用するシステムのセキュリティホールは、
「CVE情報があるセキュリティホール」「設定ミスというセキュリティホール」「アプリ固有のセキュリティホール」と３つあります。
そして設定ミスは、ソーシャルエンジアリングなどを用いてセキュリティホールを後から発現できるのも特徴です。
(他の２つのセキュリティホールを再発現させるに古い環境をデプロイさせる方法もありますが、これも設定ミスの内と言えましょう)
ストレージの公開設定の問題はAWS S3,Google Cloud Storage,Azure Blob Storage全てで見つかっており、分かり易い問題なので対策が進んでいるが、CloudFormationやTerraformなどIaCの悪用を防ぐ設定やAPIキーやその他のクレデンシャルを含むシークレットを管理となると途端に怪しくなるのではないでしょうか。
分かります。そこに切り込むことは開発者の牙城に乗り込むことになり、関係の下地、担当者の技術的な信頼性なしには全容を把握することすら困難になるでしょう。
自組織の開発(CI/CD)環境を理解しスコープに入れリスクシナリオを腹落ちさせる手筈を着実に踏んで置くことが大切です。
後で出戻ることを考えたら、一段とばす理由はありません。
特にサービスの変化の激しいクラウドサービスではWHY→WHAT→HOWの順番で伝えることに拘りましょう。
目的を明確であれば、方法論は柔軟に対応させ合意した目的に基づいて確認作業を行い、もし問題があっても納得感を作り是正への初動が圧倒的に早くなります。
どんなリスクシナリオがあるから対策すべきなのかを説明するに役に立つTop Threats to Cloud Computing The Egregious 11を説明した後、ベストプラクティスであるAWS,GCP, Azureが公開しているベストプラクティス(Well-Architected Framework)を紹介していきたいと思います。
どんなリスクシナリオがあるからクラウドの堅牢化が必要なのか
どうしてクラウドのセキュリティ対策が必要なのかと説明を求められた時、どういう事態になると組織にとって不利益になるかを納得させるためにクラウド特有の脅威をまとめたTop Threats to Cloud Computing The Egregious 11が役に立ちます。
※Top Threats to Cloud Computing The Egregious 11はCloud Security Alliance (CSA)が日本語訳を出しています。
Data Breaches
情報漏洩のシナリオです。最近の攻撃は時間をかけて行うことが多くなるため関連するログも膨大になり、「説明責任のための」調査コストが大きなリスクになります。
また、改正個人情報保護法により漏えい等報告及び本人通知が22年4月より義務化されます。要配慮個人情報の漏えいの場合は一件でもこの義務が課され不可逆的に築いてきたブランドが毀損します。
盲点となりそうなのは故意による漏えい（例：不正アクセスや従業員による持ち出し等）が含まれる点です。
業務委託でAI分析をしている場合、個人情報の扱いが含まれる運用自動化ツールを作成をしている場合などで従業員がクラウド環境で不正がないことを示せるだけの仕組みの運用ができているかはかなり怪しいのではないでしょうか。
Misconfiguration and inadequate change control
設定ミスや変更管理抜け漏れから発生するシナリオです。 ホンダの内部ネットワーク情報を格納したElasticsearchが公開されていた件や エクアドル全国民情報流出などは公開設定のミスです。
情報の漏洩、乗っ取りによる業務停止、情報資産や信用資産の破壊など積み上げてきたものを根底から破壊するシナリオが想定されます。
お客様が利用するサービスが外の認識で対策をして、社内で利用するサービスはかなり緩いセキュリティ基準なんて運用をしていないでしょうか。
脅威視点ではどちらもインターネット上にあるならば、直接中の方が目的達成コストが大幅に節約できるので社内サービスを狙います。事例もそうですがどちらも基礎的な設定ミスですが、社内利用に限定されていてもクラウドサービスが存在するのはインターネットで共同利用している環境であることを踏まえて見直してみましょう。
共同利用でいうとSub-domain take overという脆弱性があります。AWS S3で見つかることが多いですがGCPでもAzureでも発生します。Sub-domain take overは過去に利用していた指定先のクラウドサービスのリソースの乗っ取りです。原理をAWS S3で説明すると自社サービスのサイトをAWS S3で公開していた場合、DNSの設定で取得ドメインとAWS発行のサブドメインをCNAMEというレコードで関連付けた場合、AWS S3で公開していたバケットを削除しリリースする(AWSに返す)と、任意の誰かが同じサブドメインを設定したバケットを作ることできます。この状態でCNAMEのレコードがそのままだと自社ドメインのコンテンツに悪意あるコンテンツが結びつけられる可能性があります。マルウェアなどの配布を疑われ顧客に被害があった場合、補償を求められる可能性があります。
対策には説明だけでなく、ドメイン管理とサイト開発のコミュニケーションラインと変更管理を整備する必要があります。
Lack of cloud security architecture and strategy
アーキテクチャ起因のセキュリティ問題です。パブリックアクセス環境にデータベースを配置」してしまうのは致命的な損害に繋がります。またストレージにダイレクトアクセスできてしまう、例えば、CloudFrontのOrigin Access Identityを使用してS3バケットポリシーによるアクセス制限をしていない場合ではS3に直接アクセスされ意図した制御が行えない可能性があります。
ここまでは分かりやすい例ですが、リージョン移行中のアーキテクチャのアクセス制限がポリシー違反だったり、後付けの管理画面や可視化ダッシュボードが外部からアクセス可能、踏み台が作業完了後もアクセス可能で放置されているなどをアーキテクチャとして防げていないケースが散見されます。
また戦略上謳っているができていないケースもあります。例えば、C2対策はしていると言ってドメインフロンティング対策を行っていないなんてことはないでしょうか。ドメインフロンティングとはTLSのSNI (Server Name Indication) ヘッダーで指定したドメイン (フロントドメイン)を介して別のドメインへ通信する技術を悪用した手法です。具体的にはSNI (Server Name Indication) ヘッダーには正規のCDNを書いて通信し、hostヘッダーに真の目的の攻撃者の用意したサーバを指定した場合、正規のCDNとHTTPS通信をして監視を免れて攻撃者のサーバに辿り着くことができます。（T1090 Domain Fronting）
2021年ごろからドメインフロンティングの手法を使った Cobalt Strike 攻撃が観測されミャンマーなどで被害がありました。
Insufficient identity, credential, access and key management
アカウントのアクセス管理から派生する意図しないアクセスの問題です。アクセス管理がIP制御とログイン機能の制御くらいの組織ではより前段の資格情報の管理が抜けていることは珍しくなく、アカウントのプロビジョニング時のスクリーニングやオフボーディング、異動・退職時の権限クリープの問題などをそもそも認識すらされていないこともあります。
ソースコード内やdockerのレイヤーに紛れ込んだシークレットなども対象となるため、職権を超えた包括的な視点での管理が要求されます。
.gitはスプロールするように設計されています。協業者からシークレットが意図せず見えたりする可能性があるため、シークレットスキャンソリューションなどを利用し定期的に過去のコードベースのリビジョンにシークレットが残存していないか確認することが必要になります。
Account hijacking
アカウントの乗っ取りです。乗っ取った後、大抵キーやパスワードは変更されてしまいますので、アカウントの配下にあるリソースから完全に締め出され情報の盗取、破壊、改竄が可能になりそのアカウントを停止させるまで被害が続きます。特に特権アカウントが乗っ取られた場合、事業の継続自体に致命的な損害が発生する可能性があります。多要素設定をしない場合などは警告が出ますが無視してきる企業が稀にあります。権限が高いアカウントが非常時用にアクセスキーなどで共有していたり、開発環境用の強すぎる権限が放置されている場合は、鍵を期限付きで管理し、検知できる用にログを取得し、上位アカウントで侵害アカウントを停止できる用に設計を行いましょう。
Insider threat
内部犯行の問題です。これは故意によるものだけでなく某銀行のような深夜の設定ミスによる障害や、良かれと思った情報共有からの権限侵害、転職診断をするために仕事上でアクセスできるリソースをあげてしまうなど犯行を意図しない事象も含みます。故意であっても、意図せずでも、モラルや知識が欠如していてもセキュリティ侵害を起こさせない設計が求められます。
Insecure interfaces and APIs
APIの主にアクセスコントロールに起因する問題です。API自体へのアクセスもそうですが、API経由であることを過剰に信頼するとアクセスされたリソースに意図しない侵害が発生する可能性があります。検証環境と共通のAPIを使っていて検証環境から本番環境のデータを開発環境に吸い上げて不正を行うなどの可能性もあります。
Weak control plane
データプレーンをよく理解しないで管理が欠如した場合に発生する問題です。管理基盤の乗っ取りはそのまま事業継続を脅かす可能性があります。またよく理解せずに管理が欠如している場合は対応も後手後手になりコストも被害も大きくなる可能性があります。クラウドネイティブな設計が判らない場合は、最初だけでもコストを惜しまず専門家を頼るといいでしょう。ただし、頼った専門家も足元を見てきて驚異になる可能性もあるのでしっかり見極めましょう。
Metastructure and applistructure failures
監視体制の管理を主に外部に委託した場合などに見えてはいけない情報を提供してしまう問題です。お客様との同意や契約に反し、紛争や風評のリスクがあります。また情報漏洩などがあった場合在らぬ疑いをかけなくてはならないことも関係性をギクシャクさせる意味でリスクになります。
職務分掌を明確にしNeed To Know/Need To Shareに基づき委託業務の設計と必要なアクセスやマスク設計を行う必要があります。
Limited cloud usage visibility
許可を得ていないアプリなどで機密情報が漏洩したり、導入したツールのアクセス制限の問題でクラウドのサービスによるコントロールを超えた問題が発生する可能性があります。利用者も悪用者もインターネット越しに利用するのがクラウドです。リモートアクセスの主体をしっかり制御できる用にツールやサービス、そして人に対してガバナンスを効かしていく必要があります。
Abuse and nefarious use of cloud services
クラウドサービスでマルウェアのホストやスパムメールの攻撃拠点などを作れてしまう問題です。故意や不故意に関わらず、クラウドサービスの利用を停止され業務が止まる可能性があります。
監視体制を整備し業務を逸脱したアクションを検知し、排除できる仕組みを作っていくことが大切です。
とここまでで11種類です。どれも設定次第で対応できる問題ではありますが、解決には実際に運用する組織の実態に合わせ、現場の合意を取り付けながら方法論に柔軟な設計を行い、適切に運用管理しながら組織の変化に柔軟に対応しながら隙を見せず着実に仕事をしていくことが要求されます。
とは言えリスクさえしっかり伝わればスムーズさが段違いです。次のベストプラクティスの浸透も進みます。
AWS,GCP, Azureが公開しているベストプラクティス(Well-Architected Framework)
GCPはWell-Architectedとは書いていませんがベストプラクティスのポリシーは公開しています。
AWS Well-Architected Framework
Google Cloud’s Architecture Framework
Microsoft Azure Well-Architected Framework
ポリシーの準拠を確認するソリューションはどのクラウドサービスでも以下の用に提供されています。
AWS→AWS Security Hub
GCP→Security Command Center
Azure→Azure Defender&Azure Security Center
ベストプラクティス(Well-Architected Framework)の詳しい説明は次回の投稿にしたいと思います。
以上です。参考になれば幸いです。