近年広く用いられているクラウドでのセキュリティについて見ていきます。
今回は当社で一番使われているAWSでの話になりますが、他のクラウドサービスでも基本の考え方は同じです。
責任共有モデル
AWSの責任共有モデルとは、ユーザとAWSのどちらに責任があるのかを明確にする考え方のことです。
なんでもかんでも「クラウドだから安心」ではありません。自分が何に対して責任を負っているのかを自覚して、適切に管理する必要があります。
「EC2で作ったアプリが動かない…」といった自分の責任に関することを、間違ってもAWSのサポートに問い合わせてはいけません。
責任の例(雑)
EC2
ユーザ | AWS | |
ハードウェア | ○ | |
OS | ○ | |
アプリケーション | ○ | |
セキュリティ | ○ |
S3
ユーザ | AWS | |
ハードウェア | ○ | |
OS | ○ | |
データ | ○ | |
セキュリティ | ○ |
社内ルール
AWSを使う上での社内ルールがあります。必ず読んでください。
(非公開)
社内では、好ましくないリソースがあるとアラートがslackに流れる仕組みもあります。受け取ったら適切に対応してください。
(間違っても上記設定を削除してはいけません。)
過度に恐れると理解が進まないので、触ってみるのが一番です。実弾演習場の制度もあるので気軽に使ってみてください。
こちらも好ましくないリソースがあるとアラートが上がります。
IAM
IAMとは
AWSにおける、認証・認可を制御する仕組みです。
ユーザ・ポリシー・ユーザグループ・ロールがあります。
IAMユーザ
AWSのリソースを操作するユーザのことです。コンソールにログインする際にも用います。
※社内では外部ID認証を用いています。また、ニフティのセキュリティルールではコンソールログイン可能なIAMユーザ作成は許可されていません。
IAMポリシー
AWSリソースにアクセスするための権限を与えるものです。実行できる内容やリソースを決めます。
先ほどのIAMユーザを作っただけでは何もアクションが実行できません。「S3に対するフルアクセス権限」というポリシーをIAMユーザに付与することで、そのIAMユーザはS3に色々な操作ができるようになります。
ユーザと同様に、ユーザグループ・ロールにも割り当てる事ができます。
(実はリソースに直接割り当てる事も可能な場合もあります)
IAMユーザグループ
名前の通り、IAMユーザをグループ化するものです。
例えば、○○部に属する人のIAMユーザを一つのIAMグループに設定し、IAMグループに対してIAMポリシーを割り当てる事で、権限の管理が楽になります。
IAMロール
IAMユーザではなく、AWSのリソースに権限を付与する際に使います。
例えば、lambdaからS3へのアクセスをしたいときに、何も設定しなければ権限が無いためアクセスできません。
まずIAMロールを作成し、そのIAMロールに「S3に対するフルアクセス権限」というポリシーを割り当てます。
このIAMロールをlambdaに割り当てる事で、lambdaからS3にアクセスすることが可能になります。
他にも、別のAWSアカウントのポリシーを付与したロールをユーザに割り当てる事で、別アカウントのリソースにアクセスさせることができるようになります。
最小権限の原則
ユーザやリソースには、目的達成に必要な期間に限り必要な権限のみを与えるべきという考えのことです。
万が一リソースを悪意ある人が乗っ取ってしまった場合も、最低限の権限しかついていなければ被害は最小限で済みます。
AWSではIAMを適切な期間・権限に設定することで実現します。
また、これはAWSに限った話ではなく、社内の入室権限やアカウントもこの考えに基づいています。
セキュリティグループ
セキュリティグループとは、関連付けたリソースに到達できるトラフィックを制御するものです。要はファイアウォールです。
EC2を立てるときは直でグローバルipを振る場合も多いので、適切に設定しないとサーバに大量のアクセスが来ることになります。