ネコロビング!ツヴァイ!

寝ころびながら勉強したことを記録していく日記です

【AWS】責任分担セキュリティモデルとAWSの認証

●責任分担セキュリティモデルとは?

AWS上のシステムを不正アクセスから守るため利用者とAWSが協力してセキュリティを高める必要があります。

 

サービスの種類によって、利用者とAWSがそれぞれ責任を持つ範囲は変わります。

各サービス毎に利用者とAWSでそれぞれの責任範囲を明確にすることが目的です。

 

●IAM

AWSのアクセス制御を行うサービス

IAM(Identity And Access Management)

 

AWSアカウントを作成したときに作られるアカウントはルートアカウントと呼ばれる

ルートアカウントの権限はすべてのサービスを制御することができるが、ルートアカウントの権限は制御できないため情報漏洩を防ぐ意味でも普段は使用しない。

 

IAMでグループやユーザを作成します。作成されたばかりのグループやユーザにはIAMポリシーが設定されていないため何のサービスにもアクセスできない。

なので、用途によって必要最低限のアクセス権限を割り当てます。

アクセス許可と拒否のような相反するポリシーを付与された場合より厳しい権限が(この場合は拒否)が優先的に適用される。

 

各IAMユーザーはアクセスキーとシークレットキーのペアを作成、保持する

このアクセスキーとシークレットキーは各サービスに接続する認証情報として利用できるが、セキュリティの観点から各キーをEC2インスタンス上のプログラムに等に記述されることは推奨されない。

代わりにIAMロールを使用する

IAMロールはEC2インスタンスにIAMポリシーを付与するようなもの

IAMロールを割り当てられたEC2インスタンス上のプログラムはアクセスキーとシークレットキーがなくても各種サービスやリソースにアクセスすることが可能

 

IAMユーザーを全従業員1人1人に割り当てるのは非効率的

AWSには一時的に認証許可を行うSTS(Security Token Service)というものがあり、

STSと会社の従業員IDなどを紐づけて一時的にサービスへのアクセス許可を出すことができる。これをIDフェデレーションと呼ぶ

 

 

●まとめ

責任分担セキュリティモデルは利用者とAWSでそれぞれどこまでセキュリティについて責任を持つかを明確にすることである。

ルートアカウントは使用しない、IAMユーザ、IAMグループを作成する

IAMは厳しいIAMポリシーが優先される

セキュリティの観点からアクセスキー、シークレットキーをプログラムに記載するのは推奨されない、EC2インスタンスにはIAMロールを適用する

たくさんの従業員がいる会社などでは1人1人ユーザを作成するのは非効率的なのでIDフェデレーションを利用する