AWSが主催する「高度化するサイバー攻撃への Web セキュリティ対策 ~ 強化された機能と プロアクティブな運用サポート」というイベントに参加したので、そのレポートになります。 開催日時:2024年 9 月 11 日 (水) 本イベントでは「Web アプリケーションへの攻撃のトレンド」、「AWS が提供する DDoS/WAF/ボット対策」、「Web セキュリティの効果的な運用強化方法」を紹介します。 https://aws-web-security-20240911-p.splashthat.com/
スピーカー: ・ネットワーク&アプリケーションの脅威観測 ・AIの発展に伴い、AIを使って攻撃を検知していく ・Traveloka(インドネシアの旅行会社)のケース ・脅威インテリジェンス ・インフラ、アプリ、脅威インテリジェンスのあらゆる対策を一元管理することが大事 スピーカー: ・ウェブアプリに対する脅威 ・エッジサービスによる多層防御 ・DDoS攻撃対策のポイント ・AWS Shild AdvancedによるDDoS攻撃対策 ・AWS WAFのレートベースルール ・オリジンの隠ぺい ・脆弱性を悪用する攻撃対策のポイント(WAF) ・マネージドルールグループ ・マネージドルールのアップデート ・マネージドルールの管理 ・検査するボディサイズの拡張 ・悪性Botの対策のポイント ・AWS WAF Bot Control ・AWS WAF Fraud Control ・Botに対するカスタムレスポンス ・ロギング ・AWS WAFの運用サポートサービス スピーカー: ・AWSマネージドルール①HostingProviderIPList ・AWSマネージドルール②NoUserAgent_HEADER ・柔軟なルール設計 ・検知したルールを全てカウントモードとして最後に遮断可否を判別 ・遮断可否の判別ルールの仕掛け ・攻撃検知及び遮断の自動化 ・①抽出 ・②評価 ・③判断 ・④登録 ・Step Functionを使うことで、毎日1時間の作業が5分で完了できるようになった ・注意点 スピーカー: ・#OpJapan(オペレーションジャパン) ・直近のパスワードリストやゼロデイ攻撃の事例 ・NRIセキュアのSOCサービス紹介 ・NRIセキュアのAWS WAF運用監視サービスのポイント スピーカー: ・サイバーセキュリティクラウドの提供サービス紹介 ・AWS WAFの説明 ・AWS WAFのメリット ・AWS WAFの運用における課題 ・AWS Managed Rulesの運用のツボ ・高機能であるため使いこなすための知識が必要 ・WafCharmの導入で75%の運用削減が可能 ・ダッシュボードの分析機能 ・誤検知や緊急時は24/365で対応
スイーツが提供されていました。
AWS WAFやエッジサービスに特化したイベントで、AWSの取り組みや各社の工夫を聴くことができました。イベント概要
会場:Arco Tower Annex
参加費用:無料セッションメモ
サイバー攻撃のグローバルトレンド、エッジセキュリティサービスの進化とサービスイノベーション
Amazon Web Services Inc.
Perimeter Security ゼネラルマネージャー
Kavitha Prasad (カビータ・プラサード) 氏
・56%のDDoS攻撃が観測される
・全トラフィックの42%がBot通信である
・1億件の脅威が毎日発見される
・50万件が悪意のある通信
・新規脆弱性があれば90秒以内で発見
・Botを防ぐことでアプリ利用率を50%削減して基盤リソースを守る
・正規の利用者が利用しやすいようにした
・ハニーポットで攻撃を観測
・不審な動向はIPSに通報する
・脅威インテリジェンスをサービスに活かし、プロアクティブな防御AWS エッジサービスで実現するウェブアプリケーションの保護
アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト
岡 豊 氏
・サービス拒否(DDoS)
・SYNフラッド、リフレクションアタック、・・・
・アプリケーションの脆弱性
・XSS、OWASP Top 10、・・・
・悪性ボット
・脆弱性スキャン、・・・
・エッジロケーションでCloudFrontにアタッチしたAWS WAF、Route53やAWS ShieldによるDDoS対策を活用
・DNSへのDDoS攻撃に備える
・CDNを利用したオフロードを実施する
・アプリケーションレイヤーのDDoS攻撃に備える
・攻撃の対象となる領域(アタックサーフェイス)を特定し、その範囲を限定する
・適切なリソースを割り当てる
・DDoS攻撃の可視化と通知設定を行う
・DDoS攻撃の可視化するためのレポート機能
・SRTによる24/365対応
・WAF料金の免除
・同一IPアドレスからのリクエスト数が1/2/5/10分から選択し、閾値を超えたらActionを実行できる
・閾値は最小で10リクエストから設定可能
・IPアドレス以外のキーの組み合わせ(ヘッダやUAなど)でルールを構成できる(5件まで)
・マネージドプレフィックスリストを活用
・保護対象のアプリケーションに適したルールを選定する
・アプリへのリクエストの検査対象を特定する
・アプリへの攻撃の可視化と通知設定をする
・誤検知や過検知の対応
・継続的なルールのアップデート
・事前定義済みのルールセット
・一般的な攻撃ベクトルや脅威をカバー
・様々なウェブアプリケーションに適用可能な防御ルール
・マネージドルールグループは適宜アップデートが提供される
・デフォルトは自動更新だが、新ルールの評価後にルールを更新したり、以前のバージョンにロールバックが可能
・マネージドルール
・ラベル
・カスタムルール
・Scope Down Statement
・Captcha Challenge
・カスタムレスポンス
・デフォルトでは16KBのリクエストボディサイズの検査が可能(ALBとAppSyncは従来通り8KB)
・32KB/48Kb/64KBまでの上限設定が可能
・アプリケーションへのBotアクセスの可視化を行う
・Botの種類に合わせたアクションを選定する
・特定のアプリを標的とした高度なBotへ対処できるようにする
・ログインページやアカウント作成ページへの不正アクセス対策を実施する
・Common Bot(一般的なボット)
・シグネチャベース、IPレピュテーションリスト
・Target Bot(標的型ボット)
・ブラウザの調査、フィンガープリント
・不正なアカウント乗っ取りや不正なアカウント作成からの保護
・Account Takeover Prevension
・Account Creation Fraud Prevention
・Bot Controlの後続カスタムルールでカスタムレスポンスを設定
・悪性Botのラベルが付いたリクエストにkasutamureを返却
・出力先として、S3 / CloudWatch Logs / Security Lake / Data Firehose
・AWS WAF向け運用 / SOCサービス
・ルールチューニング
・ログ解析、チューニング
・独自ルール作成AWS WAFと脅威インテリジェンスを活用した攻撃検知および遮断の自動化
東日本電信電話株式会社
鈴木 雅斗 氏
菅原 捷汰 氏
・クラウドプロバイダのIPアドレスであり、エンドユーザでないアクセスを「遮断」する
・IPS事業者のハウジングなどのIPアドレスを「遮断」してしまう
・ブラウザを識別するために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経由で追加
・IPセットは上限1万件なので、棚卸すること
・XFFに注意し、CDNを遮断しないようにSOCによるフルサポートでAWS WAFの運用監視をまるっとお任せ
NRIセキュアテクノロジーズ株式会社
マネージドセキュリティサービス開発本部
関根 忠彦 氏
・Anonymousによる日本政府や日本レコード協会に対して攻撃を行うDDoS攻撃
・最適設計によるWAF能力の最大化を支援
・過検知/誤検知のチューニング
・日々の検出分析とアドバイス
・月次レポートによる傾向把握複雑な運用や専門人材は必要なし!AWS WAFを自動運用できるWafCharmとは
株式会社サイバーセキュリティクラウド CTO
渡辺 洋司 氏
・攻撃者檀君、WafCharm、・・・
・制約事項やStatement、Actionの項目など
・柔軟性の高いルール設定が可能
・導入が簡単
・コストの調整がしやすい
・最適なルールの作り方が分からない
・WAF運用専任の人材を確保できない
・新規脆弱性への対応に手が回らない
・誤検知やトラブルに時間がかかる
・バージョン管理
・どのルールで検知されたか分からない
・JSON Bodyの検査の仕組みなど
・攻撃検知状況ダッシュボード
・ログの検索機能おまけ
まとめ
AWSセキュリティサービスの活用例や運用自動化の例など、自社にも取り入れやすいノウハウをたくさん学べたので、いろいろ試してみたいと思います。
Google Cloud Next Tokyo ’24 参加レポート
横浜で開催された「Google Cloud Next Tokyo ’24」に参加してきたので、その様子をご紹介します。 開催日時:2024 年 8 月 1 日(木)- 2 日(金) 「Google Cloud Next Tokyo ’24」は、ビジネス リーダー、イノベーター、エンジニアのためのクラウドカンファレンスです。 横浜駅には本イベントんを宣伝する看板やデジタルサイネージがたくさんありました。
イベントは基調講演から始まります。
始めに、Google Cloud 日本代表の 平手智行 氏よりご挨拶です。
続いて、Google DeepMind プロダクト & エンジニアリング シニア ディレクター の セシュ アジャラプ 氏よりGemini 1.5 Proのご紹介です。
そして、Google Cloud AI ディレクター プロダクト マネージメント の アーワン メナード 氏より様々な発表がありました。
基調講演では、Gemini 1.5 Pro を使たデモも披露されました。
さらに Gemini for Google Workspace を使うと、Gmailの優先度付けやGoogle Driveからのデータ集計と書き出しなどができます。
その他にも様々な事例が紹介され、責任あるAIの実現や生成AIを用いた業務効率化の成果を目の当たりにしました。 様々な企業がGoogle Cloudの活用事例や独自サービスを展示していました。
Google Cloud認定資格を取得していると、認定者ラウンジに入ることができます。
また、Google Cloudパートナー企業に所属していれば、事前登録によりパートナーラウンジにも入ることができます。
今年も生成AIの話題が盛りだくさんでした。イベント概要
会場:パシフィコ横浜ノース
参加費用:無料
生成AIをはじめ、ビジネスに欠かせないテーマを網羅し、基調講演、ライブセッションやハンズオン等、さまざまなプログラムが2日間にわたって開催されます。会場まで
昨年のビッグサイトでの開催の時にも最寄り駅に同様の看板があり、会場までの道のりから期待が増します。基調講演
基調講演会場はGoogleらしいカラフルな仕様です。
Geminiの処理を日本で完結可能できるようになったり、Gemini がSLAをサポートするようになり、責任あるAIを実現しています。
カスタマーエージェントを使うと、Youtubeに映ったシャツが欲しいとき、URLと具体的な指示を入力すると見つけ出してくれる。
さらにコーディネートを提案してくれ、具体的なシチュエーションを入力するとそれに適した着こなしも提案してくれます。会場内
軽食も提供されており快適でした。おわりに
基調講演でも言及された通り、生成AIを活用する段階になっており、各社工夫を凝らしたサービスが展開されています。
業務効率化やセキュリティ対策に対して生成AIを活用する事例も見ることができ、様々なヒントを得ることができました。
今後のGoogle Cloudや生成AIの動向により注目です。
AWS Summit Japan 2024 参加まとめ
先日、幕張メッセで行われた「AWS Summit Japan 2024」に参加したので、その様子をご紹介します。
イベント概要
開催日時:2024 年 6 月 20 日(木)- 21 日(金)
会場:幕張メッセ
参加費用:無料
AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、全てのクラウドでイノベーションを起こすことに興味がある皆様のためのイベントです。
150以上のセッションや250以上の展示ブース、そのほかにも様々なコンテンツが用意されています。
会場入り
幕張メッセに入ると大きなボードが登場します。
受付で基調講演の指定席券と昼食の引換券がもらえます。
いつもは自由席ですが、今年は指定席になったようです。
席には座布団が置かれており持って帰ることができます。
今年はバンドが付いていて折りたためる仕様でした。
会期中は様々なグッズがもらえるので、コンパクトに収納できるのは嬉しいポイントです。
基調講演会場ではオープニングDJが流れており、テンションが上がります。
基調講演
まずは、APJ バイスプレジデント & マネージングディレクター 兼 日本マネージングディレクター である ハイミ バレス氏のご挨拶です。
これからも日本市場へ力を入れていくとのことです。
続いて、最高技術責任者(CTO)兼バイスプレジデント の ヴァーナー ボーガス氏のセッションです。
私は昨年のre:Inventでヴァーナー氏のセッションを現地で聴きましたが、歴史的な背景などを織り交ぜた引き込まれるようなお話を聞くことができます。
日本でヴァーナー氏のお話しが聴けるのは非常に珍しく、とても良い機会でした。
- プラトンやアリストテレスの時代から自動化の考えはあった
- 初期のエキスパートシステムから、深層学習や強化学習などの考え方が登場し、昨今ではLLMが頭角を現している
- LLMはまだ始まりに過ぎず、AIでどのようなことを実現していくのかを考えることが大事
- 良いAIには良いデータが必要であり、良い仕事には良い人材が必要
- 農業、ドローン、医療などへのAI技術の活用事例を紹介
昨年は「セキュリティの民主化」が話題でしたが、加えて「データの民主化」も重要なキーワードになりそうです。
高い視点で課題を見つめ、AI技術を活用する方法を検討する力が必要になることを感じました。
続いて、Anthropicの共同創設者 兼 チーフサイエンティスト である ジャレッド カプラン氏の登壇です。
Anthropicの研究やセキュリティへの取り組み、Claude3の紹介がありました。
そして、AWSジャパン執行役員 の 恒松 幹彦氏より、様々な発表がありました。
やはり、基調講演から生成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 がリリースされましたので、早速検証してみました。
アップデート概要
GuardDuty Malware Protection の拡張機能で、選択した S3 バケットへの悪意のあるファイルのアップロードを検出
GuardDutyが有効になっていない場合、GuardDuty Malware Protection for Amazon S3機能のみの有効化もできる
スキャンしたオブジェクトにはGuardDutyMalwareScanStatusというタグが付与され、タグの値によって脅威と判定されたか分かる
タグの値は以下の通り
タグの詳細は以下のドキュメントにも記載があります
- 料金はオブジェクトのサイズと数による従量課金
料金は以下の通り
- 1カ月のファイルサイズにおいて $0.79 / GB
- 1カ月のファイル数において $0.282 / 1k
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) をバケットポリシーに仕込むことで、アクセス元からマルウェアを隔離できます。
ポリシー例があるので、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 が未使用のアクセスを改善するための推奨事項を提供するようになりました。
アップデート概要
昨年、未使用のアクセスの検査機能が登場
今回のアップデートにより、未使用のアクセスを修正するための実用的な推奨事項を提供するようになった
未使用のアクセスアナライザーを作成
IAMのアクセスアナライザーから「未使用のアクセス」を選択し、アナライザーを作成します。
分析タイプを「未使用のアクセス分析」にし、その他はデフォルトのままアナライザーを作成します。
検出結果を確認
しばらく待つと、未使用のアクセス一覧が検出されます。
「未使用のIAMロール」を確認すると、詳細な推奨事項を確認できます。
今回の例では、当該ロールの確認や削除が推奨されています。
「未使用の許可」を確認すると、ポリシーの修正案を提示してくれます。
Previewボタンを押下すると、修正案のビフォー/アフターも確認できます。
まとめ
具体的な修正案を提示してくれるため、開発者が未使用のアクセス許可を調整することがより簡単になりました。
特に、AWSを使い続けていると気付かぬうちにIAMロールが増えていることが多いので、これを機に棚卸してみると良いかもしれません。
AWS IAM の MFA でパスキーが使えるようになりました
AWS re:Inforce 2024が始まり、セキュリティ関連のアップデートが増えてきました。
IAMのMFAでパスキーが使えるようになりましたので、検証してみました。
アップデート概要
ルートユーザとIAMユーザのMFA(多要素認証)でパスキーが使えるようになった
Apple MacBook の Touch ID や Windows Hello 顔認識などの組み込み認証システムなどをサポートしている
パスキーを登録
IAMで任意のユーザを作成します。
「セキュリティ認証情報」タブから「MFAデバイスの割り当て」を押下します。
「パスキーまたはセキュリティキー」を選択します。
今回はスマホでQRコードを撮影し、パスキーを登録してみました。
画面の指示通りに操作するとパスキーを登録できます。
パスキーによるログイン
一度IAMユーザをログアウトし、再度ログインしてみます。
パスキーが求められるようになりました。
デバイスに表示される手順通りに認証手続きをすると、AWSマネジメントコンソールにログインできました。
まとめ
パスキーによってより強固な認証ができそうです。
前述のニュースブログに記載の通り、最初のリリースではパスワードとパスキーの併用が必要になる点は注意です。
Amazon CloudWatch が生成AI を活用した自然言語クエリ生成をサポート
Amazon CloudWatch が生成AI を活用した自然言語クエリ生成をサポートしたので、検証してみました。
なお、こちらは昨年にプレビューが出ており、今回一般提供になりました。
アップデート概要
- Logs Insights と Metrics Insights 向けに、生成 AI を活用した自然言語クエリ生成ができるようになった
自然言語でクエリを生成してみる
CloudWatchのログのインサイトを見ると、クエリを記載するところに「Query generator」のボタンがるので押下します。
自然言語で調査したい内容を記載し、「新しいクエリを生成」を押下するとクエリが生成されます。
まとめ
簡単にクエリを生成できるため、クエリ作成経験が浅くても簡単にログを調査できるようになると思います。
生成AI技術の発達により、今後もクエリ生成関連のアップデートが増えてくると考えられるので、今後の生成AI系アップデートに期待です。