AWS セキュリティトークンサービス（セキュリティトークンサービス） STS）はAWSが提供するセキュリティツールで、制限された権限これにより、ユーザーは制御された短期的な範囲内で特権ロールにアクセスでき、ビジネス ニーズを満たすと同時に、資格情報の長期的な公開に関連するセキュリティ リスクを軽減できます。
AWSアカウント内の機密リソースに対してセキュリティチェックを実行する必要がある場合短期運用STSは、サーバー側の認証サービスを利用したいものの、この目的のためにIAMユーザーを作成・管理したくない場合に最適な選択肢です。STSによって発行される認証情報は、通常のIAMアクセスキーと同じ機能を持ちますが、ユーザー側には保存されず、有効期間の制限—通常は数分から数時間ですが、最長 36 時間続くこともあります。
AWS セキュリティトークンサービス (STS) とは何ですか?
AWS STSは ウェブサービスは、AWS Identity and Access Management (IAM) ユーザーまたはフェデレーションユーザーに、権限が制限された一時的な認証情報を発行します。これらの一時的な認証情報は、アクセスキーID、秘密アクセスキー同様にセッショントークン有効期間中、長期アクセスキーを使用せずに、指定された AWS リソースに安全にアクセスできます。
STS の一般的な用途は次のとおりです。
- クロスアカウントアクセス
- アイデンティティフェデレーション（例：SAML、OIDC、Google Workspace、Azure AD）
- 短期的な権限昇格
これらの一時認証情報の有効期間は、ビジネスシナリオと設定に応じて数分から数時間までさまざまです。これにより、STS は長期的なキー漏洩のリスクを効果的に低減し、AWS サービスをサポートします。きめ細かな時間制限付きアクセス。
STS ロールと IAM ロールの違い
STS と IAM ロール互いに補完し合う。
IAMロールとは、特定のAWS機能へのアクセスを許可する一連の権限ポリシーを含むAWSアイデンティティです。通常、ロールはAWSユーザーに直接割り当てられますが、これは長期的な過剰権限付与のリスクを伴います。
例えば、S3バケットの削除は、ほとんどの組織にとって機密性の高い稀な操作です。この権限を持つロールをユーザーに直接割り当てると、ユーザーはバケットを完全に削除できるようになり、セキュリティリスクが生じます。
STSを使用すると、ユーザーは実際のニーズこの操作を実行すると、ユーザーは一時的に特権ロールを引き継ぎます。資格情報は一定期間後に自動的に期限切れとなり、ユーザーは日常的に最小限の権限のみを保持します。リスクを大幅に軽減。
AWS STS はいつ使用すればよいですか?
STS は、AWS のさまざまな認可プロセスの中核コンポーネントです。一般的なシナリオとしては、次のようなものがあります。
1. 特権AWSリソースへの短期アクセス
一時的に高い権限を必要とするタスクに適しています。例えば、システム管理者はメンテナンス期間中にデータベースの移行などの操作を実行したり、CloudTrailの高度なログ記録を有効にしたりする必要があるものの、これらの権限を日常的に保持するべきではありません。STSを使用すると、タスクの開始時に一時的な認証情報をリクエストでき、完了すると自動的に期限切れになります。
2. アプリケーションでAWSにアクセスする
ビジネスアプリケーションやツールがAWSリソースにアクセスする必要がある場合、長期のIAM認証情報を直接使用するのはリスクの高いアプローチです。認証情報が漏洩すると、永久に公開されてしまいます。STSを使用すると、実行時に一時的な認証情報を動的に取得できるため、コードにキーをハードコーディングする必要がなくなり、いつでも権限を調整できます。
3. アイデンティティ連携シナリオ
企業は、Azure AD、Google Workspace、Oktaなどの既存のアイデンティティシステムを利用してユーザーを一元管理することがよくあります。STSとSAML/OIDCプロトコルを活用することで、ユーザーは企業アカウントを使用してAWSにログインできるため、個別のIAMユーザーを作成する必要がなくなります。このモデルは、ユーザーエクスペリエンスを向上させるだけでなく、運用コストも削減します。
4. クロスアカウントと委任アクセス
大規模企業やMSPに典型的なマルチアカウントアーキテクチャにおいて、STSは単一アカウント内のユーザーIDを一元管理し、アカウント間の信頼ポリシーを通じて、ユーザーが他のアカウントのリソースに安全にアクセスできるようにします。これにより、重複したアカウント作成の必要性が軽減され、監査とセキュリティポリシーが一元化されます。
AWS STS の仕組み
完全な STS 一時アクセス プロセスには、次の手順が含まれます。
- キャラクターを作成する: AWS 管理者は、必要な権限を含む IAM ロールを作成します。
- 信頼ポリシーの設定: ターゲット ユーザーまたは ID プロバイダーのロール信頼ポリシーを構成します。
- リクエストロール: ユーザーは STS API を呼び出して、ターゲット ロールを引き受けることを要求します。
- 検証と発行STS は信頼ポリシーをチェックし、要求の有効性を検証し、一時的な資格情報を生成します。
- リソースにアクセスする: 認証情報の有効期限が切れるまで、ユーザーは一時的な認証情報を使用して AWS API を呼び出します。
例: 運用担当者は、制限付きのS3バケットへのデータ移行を実行する必要があります。移行前に、AssumeRoleを使用して一時的なアクセス認証情報を取得します。この認証情報はタスク完了後に自動的に期限切れとなり、バケットへの再アクセスが不可能になります。
エンタープライズ実装とベストプラクティス
実際のエンタープライズクラウド移行と運用保守のシナリオでは、AWS STSの価値はセキュリティの強化それは次のような側面にも反映されています。
- コンプライアンスリスクを軽減: 短期認証情報は、最小限の権限と認証情報の管理に関する ISO 27001、GDPR、およびその他のセキュリティ規制の要件を満たすことができます。
- 簡素化された監査: 一時認証情報の使用記録は CloudTrail を通じて完全に追跡できるため、セキュリティ監査と問題の追跡が容易になります。
- 柔軟な承認: ビジネス ニーズが変化した場合 (一時的な外部チームの関与など)、外部担当者のアクセス権をすばやく生成でき、プロジェクト終了後に自動的に期限切れになります。
- 鍵の漏洩を防ぐ: コード、構成ファイル、またはサードパーティのプラットフォームに長期的なアクセス キーを保存する必要がないため、資格情報の漏洩のリスクが大幅に軽減されます。
業界事例：
ある金融機関のクライアントは、四半期決算時に、取引ログを含むS3バケットに監査チームがアクセスする必要がありました。バケットには大量の機密情報が含まれていたため、クライアントは監査チームに長期間アクセスさせたくありませんでした。そこでSTSを使用し、監査期間中12時間のみ有効な読み取り専用認証情報をチームに割り当て、タスク完了後すぐにアクセス権限が失効するようにしました。残留権限ゼロゴール。
要約と推奨事項
AWS STSはクラウド上に実装されています最小権限の原則そして安全性とコンプライアンス一時アクセス、アカウント間のコラボレーション、ID フェデレーションなど、セキュリティを確保しながら企業が俊敏性を維持するのに役立ちます。
公式 AWS エージェントとして、企業には次のような状況で STS を優先することをお勧めします。
- 機密性の高いリソースに関連するタスクにアクセスする
- 複数アカウントのコラボレーションまたはアウトソーシングされたチームアクセス
- 開発環境や自動化ツールでは動的な認証が必要
- 長期的な鍵の露出を最小限に抑えることでセキュリティを向上させることを目指す
クラウドへの移行をご検討中の方、または既にAWS環境を導入済みで権限管理にご不安のある方は、ぜひ当社のクラウドエキスパートチームにご相談ください。STSベースのセキュアアクセスソリューションをカスタマイズし、既存のアーキテクチャへのシームレスな統合をお手伝いいたします。
