AWSのアクセスキーをうっかりブログに掲載していないかGCPのCloud DLPでチェックしてみた

GCPのCloud DLPを試してみました

岩田智哉

2021.08.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CX事業本部@大阪の岩田です。GCPのCloud DLPは様々な情報タイプ（infoType）をサポートしており、AWSのアクセスキーもサポートされています。今回実際にCloud DLPを使ってAWSのアクセスキーの流出を未然に防止できないか試してみました。

やりたいこと

クラスメソッドの社員は日々様々な技術ブログを執筆していますが、ブログの中にはAWSのアクセスキーを発行する手順を含むものもあります。例えばこんなイメージです

...諸々の手順
続いて以下のコマンドを実行し、アクセスキーを発行します。
~/.aws/credentialsを以下の内容で作成します

```
[default]
aws_access_key_id=xxxxxxxxxxxxxxxxxxxx
aws_secret_access_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

続いて...略

こういったブログを執筆する場合、アクセスキーをマスクしたり発行されたアクセスキーはすぐに削除したり...といった対応がセットになるわけですが、人間のやることなので抜け漏れが発生する可能性を否定できません。万一の場合に備えて、マスクされていないアクセスキーがブログに掲載されることを未然防止するような仕組みを構築したいところです。

今回はDLPの検証を兼ねて

  • ローカル環境でmdファイルにブログを執筆
  • mdファイルのコンテンツをDLPで検査する
  • OKならmdファイルの中身をブログに公開する

という流れで手作業も組み込みつつ、Cloud DLPがmdファイルからAWSのアクセスキーを検知できるか？という点を検証してみたいと思います。

前提条件

詳細な手順は割愛していますが、前提条件として以下が必要になります

  • Cloudプロジェクトに対してDLP API が有効化されていること
  • gcloud CLIがインストールされていること

    今回は以下のバージョンを利用しました

      $ gcloud --version
  Google Cloud SDK 352.0.0
  alpha 2021.08.06
  app-engine-python 1.9.93
  beta 2021.08.06
  bq 2.0.70
  cloud-datastore-emulator 2.1.0
  core 2021.08.06
  gsutil 4.66

  • gcloud CLIを実行するユーザーアカウントもしくはサービスアカウントが適切な権限を持っていること

やってみる

まずはアクセスキーを発行するためのIAMユーザーを作成します

$ aws iam create-user --user-name dlp-test-user
{
    "User": {
        "Path": "/",
        "UserName": "dlp-test-user",
        "UserId": "xxxxxxxxxxxxxxxxxxxx",
        "Arn": "arn:aws:iam::123456789012:user/dlp-test-user",
        "CreateDate": "2021-08-15T07:27:43Z"
    }
}

続いて作成したユーザーに対してアクセスキーを発行します

$ aws iam create-access-key --user-name dlp-test-user
{
    "AccessKey": {
        "UserName": "dlp-test-user",
        "AccessKeyId": "xxxxxxxxxxxxxxxxxxxx",
        "Status": "Active",
        "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "CreateDate": "2021-08-15T07:28:20Z"
    }
}

チェック対象に認証情報ファイルの記述が含まれる場合

アクセスキーが準備できたので、チェック用にブログの下書きファイルを用意します。

blog-dlptest.md

## はじめに
## やってみる
GCPのCloud DLPでAWSのアクセスキーをチェックしてみる
### IAMユーザーの作成
```
$aws iam create-user --user-name dlp-test-user
```
### アクセスキーの発行
```
$aws iam create-access-key --user-name dlp-test-user
```
### 設定ファイルの作成


~/.aws/credentialsを以下の内容で作成します

```
[default]
aws_access_key_id=<実際はここに未マスク状態のアクセスキーが記載されています>
aws_secret_access_key=<実際はここに未マスク状態のシークレットアクセスキーが記載されています>
```

## まとめ

~/.aws/credentialsの中身は実際には未マスク状態です。このブログ下書きをCloud DLPでチェックしてみます

$ gcloud alpha dlp text inspect --content-file=blog-dlptest.md --info-types="AWS_CREDENTIALS"
result:
  findings:
  - createTime: '2021-08-15T08:05:52.137Z'
    findingId: 2021-08-15T08:05:52.140111Z540064557333625164
    infoType:
      name: AWS_CREDENTIALS
    likelihood: VERY_LIKELY
    location:
      byteRange:
        end: '487'
        start: '386'
      codepointRange:
        end: '359'
        start: '258'

うまく検出されました！

今回はAWSのアクセスキーを検出したかったので、引数のtypesにAWS_CREDENTIALSを指定しましたが、他にもGCPやAzureのクレデンシャル情報にも標準で対応しています。Cloud DLPが標準でサポートしている情報タイプ（infoType)は以下のリンクから確認できます。

infoType と infoType 検出器

チェック対象にAWS CLIの実行結果が含まれる場合

今度は少しパターンを変えてやってみます。先程はブログ内にAWSの認証情報ファイルの記述が含まれる例でしたが、AWS CLIの実行例しか含まない場合はどうでしょうか？チェック対象のmdファイルを以下の内容に書き換えます

blog-dlptest2.md

## はじめに
## やってみる
GCPのCloud DLPでAWSのアクセスキーをチェックしてみる
### IAMユーザーの作成
```
$aws iam create-user --user-name dlp-test-user
```
### アクセスキーの発行
```
$aws iam create-access-key --user-name dlp-test-user
{
    "AccessKey": {
        "UserName": "dlp-test-user",
        "AccessKeyId": "<実際はここに未マスク状態のアクセスキーが記載されています>",
        "Status": "Active",
        "SecretAccessKey": "<実際はここに未マスク状態のシークレットアクセスキーが記載されています>",
        "CreateDate": "2021-08-15T07:28:20Z"
    }
}
```


## まとめ

Cloud DLPでチェックしてみます

$ gcloud alpha dlp text inspect --content-file=blog-dlptest2.md --info-types="AWS_CREDENTIALS"
result: {}

残念ながら検出されませんでした。

チェック対象が環境変数にアクセスキーをセットしている場合

他にアクセスキーのマスク忘れが発生しそうなパターンとしてはアクセスキーを環境変数にセットするパターンがあります。こちらも試してみましょう。チェック対象のmdファイルを以下の内容に書き換えます

blog-dlptest3.md

  ## はじめに
  ## やってみる
  GCPのCloud DLPでAWSのアクセスキーをチェックしてみる
  ### IAMユーザーの作成
  ```
  $aws iam create-user --user-name dlp-test-user
  ```
  ### アクセスキーの発行
  ```
  $aws iam create-access-key --user-name dlp-test-user
  ```

  ### 環境変数の設定

  ```
  export AWS_ACCESS_KEY_ID="<実際はここに未マスク状態のアクセスキーが記載されています>",
  export AWS_SECRET_ACCESS_KEY="<実際はここに未マスク状態のシークレットアクセスキーが記載されています>"
  ```



  ## まとめ

Cloud DLPでチェックしてみます

$ gcloud alpha dlp text inspect --content-file=blog-dlptest3.md --info-types="AWS_CREDENTIALS"
result:
  findings:
  - createTime: '2021-08-15T08:16:52.953Z'
    findingId: 2021-08-15T08:16:52.957295Z6258257302515017120
    infoType:
      name: AWS_CREDENTIALS
    likelihood: VERY_LIKELY
    location:
      byteRange:
        end: '434'
        start: '321'
      codepointRange:
        end: '334'
        start: '221'

今度はうまく検出されました！！

まとめ

AWSのアクセスキー漏洩防止にGCPのCloud DLPが活用できないか調査してみました。今回試したパターンだと「aws iam create-access-keyの実行結果をマスクし忘れた場合は検出できない」という結果になりましたが、アクセスキー漏洩を機械的にチェックできる点は非常に便利なサービスだと感じました。

「Cloud DLPが検出しなかったからといって、100%安全というわけではない」ということを念頭に置きつつ、うまくブログ執筆環境と組み合わせて執筆中のブログの内容を自動チェックしたり、公開後のブログを自動チェックしたり...といった環境の構築を検討していきたいと思います。

AWS

関連記事

Cloud DLP APIで正規表現のカスタムinfoType検出器を使ってみる（Cloud Shell + curl編）

加藤 早織

2023.05.09