AWS Securityの理解しがたい選択

セキュリティ

漏洩した認証情報の隔離だけでは不十分

AWSの請求額を99パーセント以上削減する最善の方法の一つは、鍵を公開GitHubリポジトリにコミットしないことです。長年にわたって多くの人がうっかりこれをやってしまっており、それに対する防御策は劇的に改善されてきました(個人的に気に入っているのは「OIDCやSSOに由来する非一時的な認証情報を使うのはアンチパターンだ」という指摘です)が、それでも今なお起きています。

金曜日、BleepingComputerはTruffle Securityの調査結果を報じました。それによると、漏洩したAWSキーのうち数百件がルートキーであり、なぜか今も有効なまま使用可能な状態にあるとのことです。

AWS Securityには非常に優秀な人材が揃っており、「犯罪に加担しない」ことを含む数々の事柄を真剣に考えています。認証情報が漏洩したことを(通常は自動的な手段で)検知すると、AWSは速やかにその認証情報に隔離ポリシーを適用します。問題は、このポリシーが列挙する不正な挙動のリストが、プリンシパルとそれに紐づく挙動の絶えず拡大するグラフに過ぎないという点です。

これについてのAWSの熟慮された立場は、顧客の環境を壊したくないというものです。「このポリシーは、既存のリソースへの影響を避けつつ、不正利用に起因する詐欺的行為によって生じうる被害を抑えることを目的としている」とのことです。

しかし、AWSのこの熟慮された立場は間違っています。

もし私があなたの認証情報(ルート認証情報であればなおさら、まったくもって恐ろしい話ですが)にアクセスできたとして、それを無効化してしまえば、その認証情報に依存しているものはすべて動かなくなるため、あなたのワークロードは十中八九壊れてしまうでしょう。ローテーションするまで、そうしたワークロードは失敗し続けます。これは良いことではありません!

ですが、悪意ある行為者としての私が、それよりもはるかにひどいことをあなたに対してできることを断言しておきます。

まあ見ていてください

試しに、ある認証情報セットに隔離ポリシーを適用して、それを私に投げてみてください。私はSavings Plansを購入することも、あなたのS3データを読むことも、Lambda関数を変更することも、その他多くのことができなくなります。

しかし、次のようなことなら私にはできます。

• RDSに対しては、私がやりたいと思うことは何でもできます。データベースに大事なものなんて入っていませんよね?

• ssm:SendCommand / ssm:StartSessionは許可されたままなので、EC2インスタンス上でrootとしてコマンドを実行でき、それによってそのインスタンスロールの権限で処理を呼び出すことができます。

• sts:AssumeRoleを使えば、アカウント内の他の任意のロールを引き受け、その権限を得ることができます。つまり、制限リスト全体が事実上無意味になりかねないということです。

• autoscaling:CreateAutoScalingGroup / UpdateAutoScalingGroupを使えば、Auto Scalingのサービスリンクロール経由でインスタンスを起動できるため、ec2:RunInstancesの拒否設定は決して適用されません。

• cloudtrail:LookupEventsは拒否されます(これで監査ログを読むことは……できなくなりますね)が、cloudtrail:StopLoggingとDeleteTrailの両方は呼び出せます。これらはまさに想像通りのことを行います。つまり、あなたの監査ログはもう存在しなくなります。

• SESはses:GetSendQuota / ListIdentitiesアクションを拒否しますが、何が抜け落ちているかわかりますか? SendEmailです。つまり、あなたの連絡先リスト全体に向けてスパムを大量送信できてしまいます。

• sns:GetSMSAttributesのおかげであなたのSMS設定は取得できませんが、sns:Publishは問題なく使えるので、好きなだけ不正なテキストメッセージを送信できます。

• s3:DeleteObjectは拒否されますが、s3:PutObjectは許可されたままです。あなたのデータを削除することはできませんが、バケットをペタバイト単位で埋め尽くすことはできます。

• さらに、s3:PutBucketVersioning、s3:PutObjectLockConfiguration、s3:PutObjectRetention、s3:PutObjectLegalHoldのブロックにも失敗しています。つまり、たった今ペタバイト分のデータを詰め込んだあのバケットのような既存のバケットに対して、バージョニングを有効化し、Object Lockをオンにし、バケットのデフォルトとしてCOMPLIANCEモードの保持期間を2126年まで設定することも、あるいはオブジェクト単位でそれを設定することもできます。COMPLIANCE保持は、アカウントのrootやAWSサポートを含め、誰であっても短縮したり解除したりすることはできません。これを取り除く唯一の方法はAWSアカウント全体を削除することです。

• secretsmanager:GetSecretValue、ssm:GetParameter*(WithDecryption)、kms:Decryptはいずれも制限されていないため、あなたの秘密情報は今や私の秘密情報でもあります。共有は美徳ですから!

• バックアップは重要なものですが、残念ながらもう存在しません。backup:DeleteRecoveryPoint / DeleteBackupVault、そしてrds:DeleteDBSnapshotを実行してしまえばの話ですが。

• CloudFormationを使っているなら――何らかの用途でほぼ確実に使っているはずですが――cloudformation:DeleteStackが言及されていないということは、もうそれを使うことはできず、あなたのスタックはすべて消え去っているということです。

私なら違う選択をします

これは網羅的なリストではありません。この1時間ほどの間にふと思いついたことをいくつか挙げたに過ぎません。私は悪意ある行為者ではありませんが、まだ他にも数多く見落としがあるだろうことはほぼ間違いないでしょう。

AWSはほぼ間違いなくこれを変更するでしょう。私が彼らに尋ねたいのは、ただ一つ、「対応に踏み切るまでに、一体どれほど大規模な顧客インシデントが起きなければならないのか」ということです。®