本ブログは 2025 年 7 月 21 日に公開された AWS Blog “ Beyond IAM access keys: Modern authentication approaches for AWS ” を翻訳したものです。 AWS の認証において、 AWS Identity and Access Management (IAM) アクセスキーなどの長期認証情報に依存することは、認証情報の漏洩、不正な共有、窃取などのリスクをもたらします。この記事では、AWS のお客様が従来 IAM アクセスキーを使用してきた 5 つの一般的なユースケースと、検討すべきより安全な代替手段を紹介します。 AWS CLI アクセス: AWS CloudShell の活用 主に AWS コマンドラインインターフェイス (AWS CLI) アクセスのためにアクセスキーを使用している場合は、 AWS CloudShell の利用を検討してください。AWS CloudShell はブラウザベースの CLI で、使い慣れた強力な CLI 機能を提供しながら、ローカルでの認証情報管理の必要性を最小限に抑えます。 セキュリティを強化した AWS CLI: AWS IAM Identity Center より堅牢なソリューションが必要な場合は、AWS CLI v2 と AWS IAM Identity Center の組み合わせが優れた認証アプローチを提供します。この統合により、以下が可能になります。 ユーザー管理の一元化 多要素認証 (MFA) とのシームレスな統合 セキュリティ制御の強化 設定は AWS CLI ドキュメント を使用して簡単に行え、MFA は IAM Identity Center MFA ガイド に従って有効化できます。 ローカル開発: IDE 統合 ローカル環境で作業する開発者向けには、Visual Studio Code などの最新の統合開発環境 (IDE) が AWS Toolkit をサポートしており、IAM Identity Center を通じた安全な認証を提供します。これにより、スムーズな開発体験を維持しながら、長期アクセスキーが不要になります。詳細は、 AWS IDE 統合 をご覧ください。 AWS コンピューティングサービスと CI/CD アクセス アプリケーションや自動化パイプラインが AWS リソースへのアクセスを必要とする場合、AWS コンピューティングサービス ( Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 AWS Lambda ) 上で実行する場合でも、CI/CD ツールを通じて実行する場合でも、IAM ロールが理想的なソリューションを提供します。これらのロールは一時的な認証情報のローテーションを自動的に管理し、セキュリティのベストプラクティスに従います。 AWS コンピューティングサービスの場合 : コンピューティングリソースで標準の IAM ロールを使用します。実装の詳細については、 EC2 IAM ロールのドキュメント を参照してください AWS でホストされる CI/CD の場合 : AWS CodePipeline や AWS CodeBuild などを使用する場合は、 サービスリンクロール を使用してアクセス許可を安全に管理します Amazon EC2 でセルフホストされる CI/CD ツールの場合 : Jenkins や GitLab などのツールを AWS リソース上で実行している場合は、他のコンピューティングサービスと同様に IAM ロール (インスタンスプロファイル) を使用します サードパーティの CI/CD サービス (GitHub Actions、CircleCI など) については、次の 外部アクセス要件 を参照してください。 外部アクセス要件 サードパーティアプリケーションやオンプレミスワークロードが関係するシナリオでは、AWS は 3 つの方法を提供しています。 サードパーティアプリケーション : 長期アクセスキーの代わりに、IAM ロールを通じた一時的なセキュリティ認証情報を実装します。ルートユーザーのアクセスキーは絶対に使用しないでください。 サードパーティアクセスのドキュメント を参照してください オンプレミスワークロード : IAM Roles Anywhere を使用して、AWS 以外のワークロード用の一時的な認証情報を生成します。詳細については、 AWS 以外のワークロードのアクセス を参照してください CI/CD SaaS (Software as a Service) : クラウドベースの CI/CD サービスの場合は、 OpenID Connect (OIDC) と IAM ロールの統合 を使用して、永続的な認証情報の必要性を最小限に抑えます。これにより、CI/CD パイプラインは信頼関係を通じて一時的な認証情報を取得できます。実装の詳細については、AWS OIDC プロバイダーのドキュメントを参照してください ベストプラクティス: 最小権限の原則 認証方法に関係なく、常に最小権限の原則を実装してください。これにより、ユーザーとアプリケーションが必要なアクセス許可のみを持つようになります。正確な IAM ポリシーの作成に関するガイダンスについては、 最小権限の IAM ポリシーを作成するためのテクニック を参照してください。 注: AWS は AWS CloudTrail ログに基づくポリシー生成も提供しており、実際の使用パターンに基づいてアクセス許可テンプレートを作成できます。この機能については、 IAM ポリシー生成のドキュメント をご覧ください。 まとめ ここまで紹介してきたように、IAM アクセスキーに代わる安全な代替手段は数多くあり、セキュリティリスクを軽減しながら AWS 認証戦略を強化できます。CloudShell、IAM Identity Center、IDE 統合、IAM ロール、IAM Roles Anywhere などのツールを使用することで、最新のセキュリティのベストプラクティスに沿った堅牢な認証メカニズムを実装できます。重要なポイントは以下のとおりです。 長期アクセスキーを避け、一時的な認証情報を使用する ユースケースに最適な認証方法を選択する すべてのアクセス方法で最小権限の原則を実装する ポリシーの生成と管理のために AWS が提供する組み込みツールを活用する 新しいソリューションが利用可能になったら、認証方法を定期的に見直して更新する これらの変更を行うことで、セキュリティポスチャを改善するだけでなく、AWS 環境全体の認証プロセスを効率化できます。まずは現在の IAM アクセスキーのユースケースを特定し、これらのより安全な代替手段に段階的に移行することから始めてください。将来的にセキュリティ管理の負担が軽減され、セキュリティチームにとっても大きなメリットとなるでしょう。 Mitch Beaumont Mitch はオーストラリアのシドニーを拠点とする Amazon Web Services のプリンシパルソリューションアーキテクトです。オーストラリア最大級の金融サービスのお客様と協力し、構築・提供する製品や機能のセキュリティ水準を継続的に向上させる支援をしています。仕事以外では、家族との時間、写真撮影、サーフィンを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに 開発者のローカル環境では問題なくビルドが通るのに、CI（継続的インテグレーション）環境上のJenkinsなどでビルドするとエラーになってしまうような「環境依存のビルドエラー」は、多くの開発現場で一度は経験する悩みではないでしょうか。 特に、歴史の長いシステムを保守・運用している現場では、開発者のPCには最新のVisual Studioがインストールされている一方で、ビルドサーバーには古いバージョンのビルドツール（MSBuildなど）がそのまま残っているというケースが珍しくありません。 本記事では、VB.NET（Visual Basic .NET）のプロジェクトにおいて発生し

はじめに CI/CDツールとして広く利用されているJenkinsですが、Windows環境のスレーブノードやエージェントでビルドを実行する際、特有のエラーに悩まされることがあります。 その代表的なものが、ファイルパスに関連するエラーです。 Linux環境では問題なく動作していたジョブをWindows環境に移行した際や、プロジェクトのディレクトリ階層が深くなったタイミングで、突如としてビルドが失敗することがあります。 本記事では、Jenkinsでのビルド実行時に**「パスの一部が見つかりませんでした」**というエラーが発生した場合の原因と、システム設定を変更することなくJenkinsの