yuj1osm's tech blog

クラウドやセキュリティなど

AWS主催「高度化するサイバー攻撃への Web セキュリティ対策 ~ 強化された機能とプロアクティブな運用サポート」参加レポート

AWSが主催する「高度化するサイバー攻撃への Web セキュリティ対策 ~ 強化された機能と プロアクティブな運用サポート」というイベントに参加したので、そのレポートになります。

イベント概要

開催日時:2024年 9 月 11 日 (水)
会場:Arco Tower Annex
参加費用:無料

本イベントでは「Web アプリケーションへの攻撃のトレンド」、「AWS が提供する DDoS/WAF/ボット対策」、「Web セキュリティの効果的な運用強化方法」を紹介します。

https://aws-web-security-20240911-p.splashthat.com/

セッションメモ

サイバー攻撃のグローバルトレンド、エッジセキュリティサービスの進化とサービスイノベーション

スピーカー:
Amazon Web Services Inc.
Perimeter Security ゼネラルマネージャー
Kavitha Prasad (カビータ・プラサード) 氏

・ネットワーク&アプリケーションの脅威観測
 ・56%のDDoS攻撃が観測される
 ・全トラフィックの42%がBot通信である
 ・1億件の脅威が毎日発見される
 ・50万件が悪意のある通信
 ・新規脆弱性があれば90秒以内で発見

・AIの発展に伴い、AIを使って攻撃を検知していく

・Traveloka(インドネシアの旅行会社)のケース
 ・Botを防ぐことでアプリ利用率を50%削減して基盤リソースを守る
 ・正規の利用者が利用しやすいようにした

・脅威インテリジェンス
 ・ハニーポットで攻撃を観測
 ・不審な動向はIPSに通報する
 ・脅威インテリジェンスをサービスに活かし、プロアクティブな防御

・インフラ、アプリ、脅威インテリジェンスのあらゆる対策を一元管理することが大事

AWS エッジサービスで実現するウェブアプリケーションの保護

スピーカー:
アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト
岡 豊 氏

・ウェブアプリに対する脅威
 ・サービス拒否(DDoS)
  ・SYNフラッド、リフレクションアタック、・・・
 ・アプリケーションの脆弱性
  ・XSS、OWASP Top 10、・・・
 ・悪性ボット
  ・脆弱性スキャン、・・・

・エッジサービスによる多層防御
 ・エッジロケーションでCloudFrontにアタッチしたAWS WAF、Route53やAWS ShieldによるDDoS対策を活用

DDoS攻撃対策のポイント
 ・DNSへのDDoS攻撃に備える
 ・CDNを利用したオフロードを実施する
 ・アプリケーションレイヤーのDDoS攻撃に備える
 ・攻撃の対象となる領域(アタックサーフェイス)を特定し、その範囲を限定する
 ・適切なリソースを割り当てる
 ・DDoS攻撃の可視化と通知設定を行う

AWS Shild AdvancedによるDDoS攻撃対策
 ・DDoS攻撃の可視化するためのレポート機能
 ・SRTによる24/365対応
 ・WAF料金の免除

AWS WAFのレートベースルール
 ・同一IPアドレスからのリクエスト数が1/2/5/10分から選択し、閾値を超えたらActionを実行できる
 ・閾値は最小で10リクエストから設定可能
 ・IPアドレス以外のキーの組み合わせ(ヘッダやUAなど)でルールを構成できる(5件まで)

・オリジンの隠ぺい
 ・マネージドプレフィックスリストを活用

脆弱性を悪用する攻撃対策のポイント(WAF)
 ・保護対象のアプリケーションに適したルールを選定する
 ・アプリへのリクエストの検査対象を特定する
 ・アプリへの攻撃の可視化と通知設定をする
 ・誤検知や過検知の対応
 ・継続的なルールのアップデート

・マネージドルールグループ
 ・事前定義済みのルールセット
 ・一般的な攻撃ベクトルや脅威をカバー
 ・様々なウェブアプリケーションに適用可能な防御ルール

・マネージドルールのアップデート
 ・マネージドルールグループは適宜アップデートが提供される
 ・デフォルトは自動更新だが、新ルールの評価後にルールを更新したり、以前のバージョンにロールバックが可能

・マネージドルールの管理
 ・マネージドルール
 ・ラベル
 ・カスタムルール
 ・Scope Down Statement
 ・Captcha Challenge
 ・カスタムレスポンス

・検査するボディサイズの拡張
 ・デフォルトでは16KBのリクエストボディサイズの検査が可能(ALBとAppSyncは従来通り8KB)
 ・32KB/48Kb/64KBまでの上限設定が可能

・悪性Botの対策のポイント
 ・アプリケーションへのBotアクセスの可視化を行う
 ・Botの種類に合わせたアクションを選定する
 ・特定のアプリを標的とした高度なBotへ対処できるようにする
 ・ログインページやアカウント作成ページへの不正アクセス対策を実施する

AWS WAF Bot Control
 ・Common Bot(一般的なボット)
  ・シグネチャベース、IPレピュテーションリスト
 ・Target Bot(標的型ボット)
  ・ブラウザの調査、フィンガープリント

AWS WAF Fraud Control
 ・不正なアカウント乗っ取りや不正なアカウント作成からの保護
 ・Account Takeover Prevension
 ・Account Creation Fraud Prevention

Botに対するカスタムレスポンス
 ・Bot Controlの後続カスタムルールでカスタムレスポンスを設定
 ・悪性Botのラベルが付いたリクエストにkasutamureを返却

・ロギング
 ・出力先として、S3 / CloudWatch Logs / Security Lake / Data Firehose

AWS WAFの運用サポートサービス
 ・AWS WAF向け運用 / SOCサービス
  ・ルールチューニング
  ・ログ解析、チューニング
  ・独自ルール作成

AWS WAFと脅威インテリジェンスを活用した攻撃検知および遮断の自動化

スピーカー:
東日本電信電話株式会社
鈴木 雅斗 氏
菅原 捷汰 氏

AWSマネージドルール①HostingProviderIPList
 ・クラウドプロバイダのIPアドレスであり、エンドユーザでないアクセスを「遮断」する
 ・IPS事業者のハウジングなどのIPアドレスを「遮断」してしまう

AWSマネージドルール②NoUserAgent_HEADER
 ・ブラウザを識別するためにUserAgentヘッダが含まれていないリクエストを「遮断」する
 ・UserAgentが無いエンドユーザも「遮断」してしまう

・柔軟なルール設計
 ・宛先パスや送信元IPの特性に応じて遮断対象から除外

・検知したルールを全てカウントモードとして最後に遮断可否を判別
 ・GeoIPによる送信元国と検知内容を判別

・遮断可否の判別ルールの仕掛け
 ・ルールに合致したら、そのルール名のラベルを付与
 ・HostingProviderIPListラベルが付与されており、かつ、JP or USでなければ遮断

・攻撃検知及び遮断の自動化
 ・攻撃元IPアドレスの遮断登録まで(①抽出②評価③判断④登録)を自動化
 ・AWS Step Functionsを活用し、各コンポーネントを組み立てる

・①抽出
 ・スロー攻撃の検知
  ・毎日少しずつアクセスがある、3日連続で遮断されていた、など

・②評価
 ・攻撃元IPアドレスは本当に悪性か、レピュテーションサービスで調査
 ・IPVoidとAbuse IP DBの2社のレピュテーションサービスを利用

・③判断
 ・業務上必要とされるIPアドレスを「うっかり」遮断しないようにホワイトリストを用意
 ・Search Engine Spider(検索クローラー)であれば遮断しない

・④登録
 ・脅威情報配信システム(MISP)に遮断対象のIPアドレスを登録
 ・MISPに登録されたIPアドレスは、AWS WAFの遮断用「IPセット」にAPI経由で追加

・Step Functionを使うことで、毎日1時間の作業が5分で完了できるようになった

・注意点
 ・IPセットは上限1万件なので、棚卸すること
 ・XFFに注意し、CDNを遮断しないように

SOCによるフルサポートでAWS WAFの運用監視をまるっとお任せ

スピーカー:
NRIセキュアテクノロジーズ株式会社
マネージドセキュリティサービス開発本部
関根 忠彦 氏

・#OpJapan(オペレーションジャパン)
 ・Anonymousによる日本政府や日本レコード協会に対して攻撃を行うDDoS攻撃

・直近のパスワードリストやゼロデイ攻撃の事例

NRIセキュアのSOCサービス紹介

NRIセキュアのAWS WAF運用監視サービスのポイント
 ・最適設計によるWAF能力の最大化を支援
 ・過検知/誤検知のチューニング
 ・日々の検出分析とアドバイス
 ・月次レポートによる傾向把握

複雑な運用や専門人材は必要なし!AWS WAFを自動運用できるWafCharmとは

スピーカー:
株式会社サイバーセキュリティクラウド CTO
渡辺 洋司 氏

・サイバーセキュリティクラウドの提供サービス紹介
 ・攻撃者檀君、WafCharm、・・・

AWS WAFの説明
 ・制約事項やStatement、Actionの項目など

AWS WAFのメリット
 ・柔軟性の高いルール設定が可能
 ・導入が簡単
 ・コストの調整がしやすい

AWS WAFの運用における課題
 ・最適なルールの作り方が分からない
 ・WAF運用専任の人材を確保できない
 ・新規脆弱性への対応に手が回らない
 ・誤検知やトラブルに時間がかかる

AWS Managed Rulesの運用のツボ
 ・バージョン管理
 ・どのルールで検知されたか分からない

・高機能であるため使いこなすための知識が必要
 ・JSON Bodyの検査の仕組みなど

・WafCharmの導入で75%の運用削減が可能

ダッシュボードの分析機能
 ・攻撃検知状況ダッシュボード
 ・ログの検索機能

・誤検知や緊急時は24/365で対応

おまけ

ノベルティとして、AWS WAFのポーチをもらえました。

スイーツが提供されていました。

まとめ

AWS WAFやエッジサービスに特化したイベントで、AWSの取り組みや各社の工夫を聴くことができました。
AWSセキュリティサービスの活用例や運用自動化の例など、自社にも取り入れやすいノウハウをたくさん学べたので、いろいろ試してみたいと思います。

Google Cloud Next Tokyo ’24 参加レポート

横浜で開催された「Google Cloud Next Tokyo ’24」に参加してきたので、その様子をご紹介します。

イベント概要

開催日時:2024 年 8 月 1 日(木)- 2 日(金)
会場:パシフィコ横浜ノース
参加費用:無料

Google Cloud Next Tokyo ’24」は、ビジネス リーダー、イノベーター、エンジニアのためのクラウドカンファレンスです。
生成AIをはじめ、ビジネスに欠かせないテーマを網羅し、基調講演、ライブセッションやハンズオン等、さまざまなプログラムが2日間にわたって開催されます。

cloudonair.withgoogle.com

会場まで

横浜駅には本イベントんを宣伝する看板やデジタルサイネージがたくさんありました。
昨年のビッグサイトでの開催の時にも最寄り駅に同様の看板があり、会場までの道のりから期待が増します。

基調講演

イベントは基調講演から始まります。
基調講演会場はGoogleらしいカラフルな仕様です。

始めに、Google Cloud 日本代表の 平手智行 氏よりご挨拶です。

  • Google Cloudは40リージョンに拡大し、それらを320万キロを超える高性能で信頼の高いネットワークで接続
  • 日本をデータのハブとして位置づけ、日本と北米とアジアを結ぶ海底ケーブルを開通する計画
  • AIを「試す」段階から「使う」段階にシフトしており、Gemini 1.5 Proはビジネスの課題に総合的に解決
  • 「生成AIモデル」の活用から「生成AIエージェント」の活用へシフトしており、AIエージェントで業務全体をカバー

続いて、Google DeepMind プロダクト & エンジニアリング シニア ディレクター の セシュ アジャラプ 氏よりGemini 1.5 Proのご紹介です。

  • Gemini 1.5 Proは、200万トークンを処理可能で、動画2時間や音声22時間に相当
  • 大胆かつ責任あるAIに注力
  • SynthIDを使って、生成AIコンテンツに電子透かしを入れてフェイク拡散を防止

そして、Google Cloud AI ディレクター プロダクト マネージメント の アーワン メナード 氏より様々な発表がありました。
Geminiの処理を日本で完結可能できるようになったり、Gemini がSLAをサポートするようになり、責任あるAIを実現しています。

基調講演では、Gemini 1.5 Pro を使たデモも披露されました。
カスタマーエージェントを使うと、Youtubeに映ったシャツが欲しいとき、URLと具体的な指示を入力すると見つけ出してくれる。
さらにコーディネートを提案してくれ、具体的なシチュエーションを入力するとそれに適した着こなしも提案してくれます。

さらに Gemini for Google Workspace を使うと、Gmailの優先度付けやGoogle Driveからのデータ集計と書き出しなどができます。

その他にも様々な事例が紹介され、責任あるAIの実現や生成AIを用いた業務効率化の成果を目の当たりにしました。

会場内

様々な企業がGoogle Cloudの活用事例や独自サービスを展示していました。

Google Cloud認定資格を取得していると、認定者ラウンジに入ることができます。

また、Google Cloudパートナー企業に所属していれば、事前登録によりパートナーラウンジにも入ることができます。
軽食も提供されており快適でした。

おわりに

今年も生成AIの話題が盛りだくさんでした。
基調講演でも言及された通り、生成AIを活用する段階になっており、各社工夫を凝らしたサービスが展開されています。
業務効率化やセキュリティ対策に対して生成AIを活用する事例も見ることができ、様々なヒントを得ることができました。
今後のGoogle Cloudや生成AIの動向により注目です。

AWS Summit Japan 2024 参加まとめ

先日、幕張メッセで行われた「AWS Summit Japan 2024」に参加したので、その様子をご紹介します。

イベント概要

開催日時:2024 年 6 月 20 日(木)- 21 日(金)
会場:幕張メッセ
参加費用:無料

AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、全てのクラウドイノベーションを起こすことに興味がある皆様のためのイベントです。

150以上のセッションや250以上の展示ブース、そのほかにも様々なコンテンツが用意されています。

aws.amazon.com

会場入り

幕張メッセに入ると大きなボードが登場します。

受付で基調講演の指定席券と昼食の引換券がもらえます。
いつもは自由席ですが、今年は指定席になったようです。

席には座布団が置かれており持って帰ることができます。
今年はバンドが付いていて折りたためる仕様でした。
会期中は様々なグッズがもらえるので、コンパクトに収納できるのは嬉しいポイントです。

基調講演会場ではオープニングDJが流れており、テンションが上がります。

基調講演

まずは、APJ バイスプレジデント & マネージングディレクター 兼 日本マネージングディレクター である ハイミ バレス氏のご挨拶です。
これからも日本市場へ力を入れていくとのことです。

続いて、最高技術責任者(CTO)兼バイスプレジデント の ヴァーナー ボーガス氏のセッションです。
私は昨年のre:Inventでヴァーナー氏のセッションを現地で聴きましたが、歴史的な背景などを織り交ぜた引き込まれるようなお話を聞くことができます。
日本でヴァーナー氏のお話しが聴けるのは非常に珍しく、とても良い機会でした。

  • プラトンアリストテレスの時代から自動化の考えはあった
  • 初期のエキスパートシステムから、深層学習や強化学習などの考え方が登場し、昨今ではLLMが頭角を現している
  • LLMはまだ始まりに過ぎず、AIでどのようなことを実現していくのかを考えることが大事
  • 良いAIには良いデータが必要であり、良い仕事には良い人材が必要
  • 農業、ドローン、医療などへのAI技術の活用事例を紹介

昨年は「セキュリティの民主化」が話題でしたが、加えて「データの民主化」も重要なキーワードになりそうです。
高い視点で課題を見つめ、AI技術を活用する方法を検討する力が必要になることを感じました。

続いて、Anthropicの共同創設者 兼 チーフサイエンティスト である ジャレッド カプラン氏の登壇です。
Anthropicの研究やセキュリティへの取り組み、Claude3の紹介がありました。

そして、AWSジャパン執行役員 の 恒松 幹彦氏より、様々な発表がありました。

  • Anthropic の Claude3 が東京リージョンで利用可能
  • Amazon Q Business 日本語版リリース
  • 新しい資格、AIFとMLAの発表
  • AWS生成AI実用化推進プログラムを発表

やはり、基調講演から生成AIが満載でした。

会場の様子

とても広い会場に、たくさんのセッション会場や企業ブースが盛り上がりを見せていました。

認定者ラウンジは昨年より広くなっていました。

AWS DeepRacerの会場では、今年もアツいレースが繰り広げられていました。

映えスポットもあります。

Chaos Kittyの体験もしてきました。
ブロックと IoT 電球でできた物理的なアーキテクチャは、AWS環境におけるシンプルな三層構造のWeb アプリを表しています。
設定が変更されたときは IoT 電球の色が緑 (安全) から赤 (設定違反) に変わるため、全て緑になるようにAWSコンソールから設定を変更していきます。

AWS Snowballの実物を持つことができました。

おわりに

今年のAWS Summitも非常に楽しめました。
やはり生成AIに関する話題が多かったように思います。
多くの企業が生成AIを使ったサービスを出しており、生成AIがどんどん普及して当たり前のようにサービスに組み込まれていることを実感しました。
以上、簡単ですがAWS Summit Japan 2024の様子をご紹介させていただきました。

Amazon GuardDuty Malware Protection for Amazon S3 がリリースされました

AWS re:Inforce 2024にて、Amazon GuardDuty Malware Protection for Amazon S3 がリリースされましたので、早速検証してみました。

aws.amazon.com

aws.amazon.com

アップデート概要

  • GuardDuty Malware Protection の拡張機能で、選択した S3 バケットへの悪意のあるファイルのアップロードを検出

  • GuardDutyが有効になっていない場合、GuardDuty Malware Protection for Amazon S3機能のみの有効化もできる

  • スキャンしたオブジェクトにはGuardDutyMalwareScanStatusというタグが付与され、タグの値によって脅威と判定されたか分かる
    タグの値は以下の通り

    • NO_THREATS_FOUND : 潜在的な脅威を検出しなかった
    • THREATS_FOUND : 潜在的な脅威を検出した
    • UNSUPPORTED : 当該オブジェクトのスキャンをサポートしていない
    • ACCESS_DENIED : オブジェクトにアクセスできない
    • FAILED : マルウェアスキャンを実行できない

タグの詳細は以下のドキュメントにも記載があります

docs.aws.amazon.com

  • 料金はオブジェクトのサイズと数による従量課金 料金は以下の通り
    • 1カ月のファイルサイズにおいて $0.79 / GB
    • 1カ月のファイル数において $0.282 / 1k

aws.amazon.com

Malware Protection for Amazon S3を有効化

GuardDutyの「S3のMalware Protection」から「S3のMalware Protectionを有効化」を押下します。

スキャン対象のS3バケットは「S3バケット内のすべてのオブジェクト」、タグ付けは「オブジェクトにタグを付ける」を選択します。
Malware Protection for Amazon S3機能のためのIAMロールを作成します。
「アクセス許可を表示」を押下します。

IAMロールに必要なポリシーが表示されるので、これらをコピーしておきます。

参考までにポリシーと信頼関係は以下のようになっています。

ポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowManagedRuleToSendS3EventsToGuardDuty",
      "Effect": "Allow",
      "Action": [
        "events:PutRule",
        "events:DeleteRule",
        "events:PutTargets",
        "events:RemoveTargets"
      ],
      "Resource": [
        "arn:aws:events:ap-northeast-1:3<accountID>:rule/DO-NOT-DELETE-AmazonGuardDutyMalwareProtectionS3*"
      ],
      "Condition": {
        "StringLike": {
          "events:ManagedBy": "malware-protection-plan.guardduty.amazonaws.com"
        }
      }
    },
    {
      "Sid": "AllowGuardDutyToMonitorEventBridgeManagedRule",
      "Effect": "Allow",
      "Action": [
        "events:DescribeRule",
        "events:ListTargetsByRule"
      ],
      "Resource": [
        "arn:aws:events:ap-northeast-1:<accountID>:rule/DO-NOT-DELETE-AmazonGuardDutyMalwareProtectionS3*"
      ]
    },
    {
      "Sid": "AllowPostScanTag",
      "Effect": "Allow",
      "Action": [
        "s3:PutObjectTagging",
        "s3:GetObjectTagging",
        "s3:PutObjectVersionTagging",
        "s3:GetObjectVersionTagging"
      ],
      "Resource": [
        "arn:aws:s3:::test-s3mal-bucket/*"
      ]
    },
    {
      "Sid": "AllowEnableS3EventBridgeEvents",
      "Effect": "Allow",
      "Action": [
        "s3:PutBucketNotification",
        "s3:GetBucketNotification"
      ],
      "Resource": [
        "arn:aws:s3:::test-s3mal-bucket"
      ]
    },
    {
      "Sid": "AllowPutValidationObject",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::test-s3mal-bucket/malware-protection-resource-validation-object"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::test-s3mal-bucket"
      ]
    },
    {
      "Sid": "AllowMalwareScan",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::test-s3mal-bucket/*"
      ]
    },
    {
      "Sid": "AllowDecryptForMalwareScan",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-northeast-1:<accountID>:key/<key_id>",
      "Condition": {
        "StringLike": {
          "kms:ViaService": "s3.*.amazonaws.com"
        }
      }
    }
  ]
}

信頼関係

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "malware-protection-plan.guardduty.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

続いて、IAMロールを作成します。
エンティティタイプはカスタム信頼ポリシーとし、コピーした信頼関係をペーストします。

ポリシーはいったんロールを作成し後にインラインポリシーとして追加します。
ロール名を入力しロールを作成します。

インラインポリシーのアクセス許可で、コピーしたポリシーをペーストします。

ポリシー名を入力しポリシーを作成します。

S3のMalware Protectionを有効化の画面に戻り、作成したIAMロールを選択し、「有効にする」を押下します。

S3のMalware Protectionが有効化されました。

スキャン状況の監視ができるようです。

IAMポリシーではS3とEventBridgeへの権限がありました。
そこで、EventBridgeを確認してみると、「DO-NOT-DELETE-AmazonGuardDutyMalwareProtectionS3-<文字列>」というルールが作成されています。
イベントパターンとターゲットを見ると、S3バケットにオブジェクトが作成されたらguardduty-malware-protection-planが起動して、スキャンが行われる仕組みのようです。

マルウェアを検知させる

S3バケットにeicarファイルをアップロードします。
ちなみに、S3のMalware Protectionが有効化したときに「malware-protection-resource-validation-object」というテストファイルも自動作成されているようです。

モニタリングを見ていると、スキャンされており感染判定されていることを観測できます。

eicarファイルには「GuardDutyMalwareScanStatus : THREATS_FOUND」というタグが付いており、潜在的な脅威を検出したと判定されていることが分かります。

ちなみに、有効化時に作られた「malware-protection-resource-validation-object」というテストファイルのタグを見てみると、「GuardDutyMalwareScanStatus : NO_THREATS_FOUND」というタグが付いており、潜在的な脅威と判定されなかったことが分かります。

検出結果の確認

それでは検出結果を見ていきます。
GuardDutyの「検出結果」を見ると、重要度「高」で検出結果タイプが「Object:S3/MaliciousFile」が検出されています。

詳細を見ると、検出理由やオブジェクトの情報が表示されています。

マルウェアから保護する

スキャン後にオブジェクトにタグ付けが行われるので、タグベースのアクセス制御 (TBAC) をバケットポリシーに仕込むことで、アクセス元からマルウェアを隔離できます。

docs.aws.amazon.com

ポリシー例があるので、S3バケットポリシーに設定します。

タグが「GuardDutyMalwareScanStatus": "NO_THREATS_FOUND"」以外のオブジェクトへのアクセスを拒否するという内容です。

タグベースのアクセス制御 (TBAC) をバケットポリシー例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "NoReadExceptForClean",
            "Effect": "Deny",
            "NotPrincipal": {
                "AWS": [
                    "arn:aws:iam::555555555555:root",
                    "arn:aws:iam::555555555555:role/IAM-role-ARN",
                    "arn:aws:iam::555555555555:assumed-role/role-ARN/GuardDutyMalwareProtection"
                ]
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "s3:ExistingObjectTag/GuardDutyMalwareScanStatus": "NO_THREATS_FOUND"
                }
            }
        },
        {
            "Sid": "OnlyGuardDutyCanTag",
            "Effect": "Deny",
            "NotPrincipal": {
                "AWS": [
                    "arn:aws:iam::555555555555:root",
                    "arn:aws:iam::555555555555:role/IAM-role-ARN",
                    "arn:aws:iam::555555555555:assumed-role/role-ARN/GuardDutyMalwareProtection"
                ]
            },
            "Action": "s3:PutObjectTagging",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ]
        }
    ]
}

試しに無害のファイルをS3バケットにアップロードします。

こちらは「GuardDutyMalwareScanStatus : NO_THREATS_FOUND」でした。

AWS CloudShellでローカルコピーしてみると、eicarファイルだけブロックされました。

$ aws s3 cp s3://test-s3mal-bucket/test.txt ./
download: s3://test-s3mal-bucket/test.txt to ./test.txt           
$ aws s3 cp s3://test-s3mal-bucket/eicar.com ./
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden

まとめ

Amazon GuardDuty Malware Protection for Amazon S3 を試してみました。
検出だけでなく、隔離の仕組みを簡単に実装できるのは嬉しい点です。

ユースケースとしては、不特定多数のユーザがS3バケットへファイルをアップロードできるようなアプリケーションで効果を発揮すると思います。
一方で、ログ保存など内部で使われていて、不特定多数のユーザからアップロードする余地のないS3バケットには、無理に設定する必要はなさそうです。
用途に応じて活用しましょう。

タグの付与やEventBridgeを自由にカスタマイズできるので、運用者に通知メールを送ったり、他のバケットへ隔離するといったこともできそうです。
要件に応じて柔軟に設計すると良いでしょう。

GuardDutyの活用範囲もどんどん増えているので、ぜひ活用してみてください。

AWS IAM Access Analyzer が未使用のアクセスを改善するための推奨事項を提供

AWS re:Inforce 2024にて、AWS IAM Access Analyzer が未使用のアクセスを改善するための推奨事項を提供するようになりました。

aws.amazon.com

aws.amazon.com

アップデート概要

  • 昨年、未使用のアクセスの検査機能が登場

  • 今回のアップデートにより、未使用のアクセスを修正するための実用的な推奨事項を提供するようになった

未使用のアクセスアナライザーを作成

IAMのアクセスアナライザーから「未使用のアクセス」を選択し、アナライザーを作成します。

分析タイプを「未使用のアクセス分析」にし、その他はデフォルトのままアナライザーを作成します。

検出結果を確認

しばらく待つと、未使用のアクセス一覧が検出されます。

「未使用のIAMロール」を確認すると、詳細な推奨事項を確認できます。
今回の例では、当該ロールの確認や削除が推奨されています。

「未使用の許可」を確認すると、ポリシーの修正案を提示してくれます。

Previewボタンを押下すると、修正案のビフォー/アフターも確認できます。

まとめ

具体的な修正案を提示してくれるため、開発者が未使用のアクセス許可を調整することがより簡単になりました。
特に、AWSを使い続けていると気付かぬうちにIAMロールが増えていることが多いので、これを機に棚卸してみると良いかもしれません。

AWS IAM の MFA でパスキーが使えるようになりました

AWS re:Inforce 2024が始まり、セキュリティ関連のアップデートが増えてきました。
IAMのMFAでパスキーが使えるようになりましたので、検証してみました。

aws.amazon.com

aws.amazon.com

アップデート概要

  • ルートユーザとIAMユーザのMFA(多要素認証)でパスキーが使えるようになった

  • Apple MacBook の Touch ID や Windows Hello 顔認識などの組み込み認証システムなどをサポートしている

パスキーを登録

IAMで任意のユーザを作成します。
「セキュリティ認証情報」タブから「MFAデバイスの割り当て」を押下します。

「パスキーまたはセキュリティキー」を選択します。

今回はスマホQRコードを撮影し、パスキーを登録してみました。
画面の指示通りに操作するとパスキーを登録できます。

パスキーによるログイン

一度IAMユーザをログアウトし、再度ログインしてみます。

パスキーが求められるようになりました。

バイスに表示される手順通りに認証手続きをすると、AWSマネジメントコンソールにログインできました。

まとめ

パスキーによってより強固な認証ができそうです。
前述のニュースブログに記載の通り、最初のリリースではパスワードとパスキーの併用が必要になる点は注意です。

Amazon CloudWatch が生成AI を活用した自然言語クエリ生成をサポート

Amazon CloudWatch が生成AI を活用した自然言語クエリ生成をサポートしたので、検証してみました。

aws.amazon.com

なお、こちらは昨年にプレビューが出ており、今回一般提供になりました。

aws.amazon.com

アップデート概要

  • Logs Insights と Metrics Insights 向けに、生成 AI を活用した自然言語クエリ生成ができるようになった

自然言語でクエリを生成してみる

CloudWatchのログのインサイトを見ると、クエリを記載するところに「Query generator」のボタンがるので押下します。

自然言語で調査したい内容を記載し、「新しいクエリを生成」を押下するとクエリが生成されます。

まとめ

簡単にクエリを生成できるため、クエリ作成経験が浅くても簡単にログを調査できるようになると思います。
生成AI技術の発達により、今後もクエリ生成関連のアップデートが増えてくると考えられるので、今後の生成AI系アップデートに期待です。