カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

AWS 環境における Generative AI とセキュリティのジレンマ

どうもセキュリティエンジニアリングの西川です。 寒いのは好きではないのですが、寒くなってくると猫が布団に入ってくるので最高です。

ラスベガスで開催された AWS re:Invent 2024 に参加していました。 その中でも Generative AI を利用したセキュリティ対策やその他もろもろ便利機能が共有されていました。

これは当然と言えば当然で、セキュリティエンジニアは市場に少ないですし、セキュリティエンジニアの中でもスキルが十分に足りていないといったことも考えられ、それを補うためにGenerative AI を使いましょうという流れは自然だと思います。

セキュリティへの Generative AI 活用が始まる一方でジレンマもありまして、今回は共有と注意喚起として書いてみたいと思います。

荒ぶる Amazon GuardDuty

最近 Amazon Q が AWS のリソースの設定を自然言語で確認すると、その設定を返してくれるようになりました。

それから、同僚の @manaty0226 さんが、この前 Generative AI を使用したセキュリティ対策について書いていた内容を私も一緒に検証していたりしていました。

kaminashi-developer.hatenablog.jp

ということで、すでに使った方がいらっしゃればわかるかもしれませんが、これらの振る舞いについて Amazon GuardDuty が脅威としてアラートをあげてくれます(困惑) 。

実際に弊社のエンジニアが Amazon Q でリソースの設定を確認したところ下記のアラートがあがりました。

  • High:「anomalously invoking APIs commonly used in Persistence tactics.」
  • High:「anomalously invoking APIs commonly used in Exfiltration tactics.」
  • High:「anomalously invoking APIs commonly used in PrivilegeEscalation tactics.」
  • High:「anomalously invoking APIs commonly used in Impact tactics.」
  • Low: 「anomalously invoking APIs commonly used in Discovery tactics.」

内容的に怖すぎますよね。一気にこれだけ出てくることもそうですし、さらに High と判定されているとなれば、攻撃を受けているかも!?と思うのは必然です。

Amazon Q の挙動と検知理由の推測

今までカミナシで GuardDuty のアラートが上がっていたものはほとんど検証目的で、あっても Low の過検知なので今回は本当に焦りました。前述の @manaty0226 と一緒に検証していた際は実施内容と検知内容から誤検知であることが推測できたので問題なかったのですが、 Amazon Q への問い合わせは弊社のワークロードのアカウントでアラートが上がったので、すぐに担当者にヒアリングして Amazon Q が原因であることがわかりました。

Amazon Q に関してはログインしているユーザーに Assume Role し、 API を叩きにいっているように見受けられるのですが、 その振る舞いが環境をスキャンしているように GuardDuty には見えるようです。機械学習ベースでの検知なのであくまでも推測ではありますが、おそらくそうなのではないかと。

同様に、https://kaminashi-developer.hatenablog.jp/entry/2024/12/07/aws-reinvent-genai-security のワークショップの内容も Security Hub の設定値を確認するため、それが攻撃と捉えられた可能性があります。

クラウドにおける Generative AI セキュリティの今後

今後の課題としては、AI によるただの設定値の確認なのか、それとも本当の攻撃なのかというのがわかりづらくなるということが考えられます。こういったアラートを一律で除外してしまうと逆に攻撃を検知できなくなってしまい本末転倒です。一方で誠実にアラートと向き合うと今度はセキュリティエンジニアが過検知に悩まされる可能性があります。まさにジレンマです。

GuardDuty が呼び出し元にフォーカスして、 Amazon Q から呼び出されたのかとか、信頼されているアプリが呼び出されたのかで Severity をコントロールするとかしてくれないと、 この問題は無くならないように思います。その場合は、攻撃者が Amazon Q や信頼されたアプリを悪用する攻撃は許容するということになるのですが、 そうでもしないとこのジレンマは無くならないのではないかもなーと考えています。 まあでも何かが解決したら新たなジレンマが生まれたりするのでこれが完璧な解決策であるとは思っていませんが、一旦こういうことができるようになると嬉しいですね。

最後に

今後 Generative AI と セキュリティがどのように発展していくかは定かではありませんが、同様の問題が今後も繰り返される可能性があります。何か良い方法や考えをお持ちの方は教えていただけると嬉しいです!

カミナシでは技術と猫が好きなソフトウェアエンジニアを募集しています。ご応募お待ちしております!

https://herp.careers/v1/kaminashi/requisition-groups/ae8150ab-e044-41d8-b034-ac2987cc29db