[小ネタ]CloudWatch Logsの機密データ保護機能でシークレットアクセスキーがマスキングされるパターンを調べてみた

CloudWatch Logsの機密データ保護機能とは？

re:Invent2022で発表されたAmazon CloudWatch Logsのアップデートです。

速報記事はこちら⇒[アップデート]Amazon CloudWatch Logsでログデータに含まれた機密情報を保護出来るようになりました #reinvent

アップデート内容と、実際に試してみた内容が上記の記事にわかりやすくまとめられています。上記記事の中ではAddress、AWSSecretKey、IPAddressのマスキングを試していますが、AWSSecretKeyについてはうまくいかなかったことが記されていました。

最後にAWSSecretKeyを試したのですが、マスクされませんでした。。マスク出来た方は教えてください。

そこで、AWSのシークレットアクセスキーがマスキングされるパターンを色々試して調べてみました。

準備：ロググループにData Protectionの設定

まずロググループを作成し、作成したロググループをチェックしてアクション⇒Edit data protection policyを選択します。

AwsSecretKeyを選択した状態で変更の保存をします。

Data identifiersで選択した名前をそのまま使う

元記事でも試されていましたが、上記の設定画面の文字列AwsSecretKeyとシークレットアクセスキーをイコールでつなげてログに出力してみます。

確かにマスキングされていません。

クレデンシャルの内容をそのまま使う

CLIを使用する場合、ローカルの.awsにクレデンシャルファイルを作成しているかと思います。ここに記載されている内容を出力してみます。

マスキングされました。

ちなみに、アクセスキーはマスキングされませんでした。

=以外の記号で区切る

=の代わりにコロンやスペースを使ってもマスキングされました。

カンマやピリオドではできませんでした。

カッコを使う

見出しのようにカッコで区切っても大丈夫でした。しかし、カッコの種類によっては閉じカッコが消えてしまいました。

Display⇒Temporarily unmask protected dataでマスキングを一時的に解除すると、閉じカッコはちゃんと存在していました。

この挙動を見て、あれ？と思ったので、以下のパターンを試してみました。

aws_secret_access_key = (シークレットアクセスキー
aws_secret_access_key = )シークレットアクセスキー
aws_secret_access_key = シークレットアクセスキー「
aws_secret_access_key = シークレットアクセスキー」
aws_secret_access_key = *シークレットアクセスキー

これらはすべて記号部分も含めてマスキングされました。しかし、以下のパターンだとマスキングされませんでした。

aws_secret_access_key = +シークレットアクセスキー
aws_secret_access_key = /シークレットアクセスキー

シークレットアクセスキーの先頭や末尾にカッコで補足を書き加えてみました。

aws_secret_access_key = シークレットアクセスキー(personal)
aws_secret_access_key = シークレットアクセスキー[personal]
aws_secret_access_key = (personal)シークレットアクセスキー

それぞれ以下のようになりました。

aws_secret_access_key以外の名前

aws_secret_access_keyという名前でなくても、以下のパターンでもマスキングされました。

aws_secret_keyやaws_key、aws_secret、またsecretのみではマスキングされませんでした。

アンダーバーはスペースに変えても大丈夫でした。

しかし、ハイフンに変えるとだめでした。

Pascal Caseもだめでした。

大文字にする

大文字にしても問題ないようです。（途中で余計なログが入ってしまったので、消しています）

文章にする

文章にしてもうまくいきました。

andやorで複数列挙してもちゃんとマスキングされました。

しかし3つ以上つなげると3つ目からはマスキングされませんでした。

また、このような文章はだめみたいです。

シークレットアクセスキーかどうかの判定

シークレットアクセスキーをdummyという文字列にしたらマスキングされませんでした。

しかし、40文字のダミー文字列にしたところ、マスキングされました。

aws_secret_access_key = dummydummydummydummydummydummydummydummy

また、本物のシークレットアクセスキーから1文字削ったり、アルファベットを1文字追加したりしたところ、マスキングされませんでした。（1番目の例は末尾の1文字を削り、2番目の例はシークレットアクセスキーの末尾にaを足しています）

しかし、「カッコを使う」のところで少し触れたように、カッコやピリオドを追加するとシークレットアクセスキー部分のみがちゃんとマスキングされました。

シークレットアクセスキーかどうかは、英数と特定の記号（/と+）で構成された連続した40文字の文字列かどうかで判定しているようです。39文字以下や、41文字以上の場合はシークレットアクセスキーと判定されず、マスキングされません。ただし、シークレットアクセスキーに使われない文字（カッコやピリオドなど、その他の記号）が前後についている場合は、41文字以上になってもちゃんとマスキングしてくれるみたいです。

ただ、40文字の文字列を単体でログに出力してもマスキングされないので、この記事で挙げたような、シークレットアクセスキーだと示すための何らかの文字列は必要そうです。

おわりに

今回アップデートで追加されたCloudWatch Logsの機密データ保護機能は、パターンマッチングと機械学習を利用して機密データを検出しているそうですが、このパターンはどうかな？と色々試してみるのは楽しかったです。

元記事を読んでいて、ふと気になったので試してみた記事ですが、誰かのお役に立てば幸いです。