セキュリティ
ここからは、個々のAWSリソースについて解説していきます。まず、セキュリティに関するAWSリソースから風呂敷を広げていきます。なぜセキュリティを１番最初に持ってきたかというと、それだけ大事なことだからです。 ニュースなどで、顧客情報の漏洩を謝罪する場面を見たことはありませんでしょうか。そういった、セキュリティ事故の裏側で起こっていることを、エンジニア、ハッカー、ユーザーの目線からまとめました。横に並ぶAWSリソースは、それぞれの場面でよく用いられるものです。 エンジニアは、システムを公開する前に防御を組みます。ハッカーがどこを狙ってくるか、裏の裏まで読んで穴を塞いでいきます。防御が完成したら、システムを公開し、ユーザーが利用を開始します。ところが、悔しくもハッカーに防御を破られ、攻撃がシステムに届いてしまいました。エンジニアはハッカーからの攻撃を検出し、ユーザーは利用を中止します。その後、エンジニアはなぜ防御が破られてしまったのかを調査し、適切な対処をして、システムを復旧させます。そして、ユーザーは利用を再開するという流れになります。 セキュリティ事故を未然に防ぐために、いかにして完璧な防御を組むかが重要になります。また、被害を最小限留めるためにも、すばやく攻撃を検出して対処することが大切です。それらができるかはエンジニアの腕に掛かっているので、平和を守る警察官になる気分で、システムを守るエンジニアになっていただければと思います。
AWS IAM
AWS Identity and Access Management(IAM)は、IDとアクセスを管理するAWSリソース。アカウントやAWSリソースの操作権限を管理するよ。
AWSを用いてシステムを作る企業は、AWS IAMでエンジニアやAWSリソースを管理している。AWS IAMで、適切にIDとアクセスを管理することにより、セキュリティ事故の防止をすることができるよ。
AWS IAMの機能
AWS IAMには、主に4つの機能があるよ。
IAMユーザーは、エンジニアに割り当てるIDのこと。
AWSを使い始める際、最初にAWSアカウントを作成する。AWSアカウントからIAMユーザーを作成し、１人１つずつ割り当てます。エンジニアは、IAMユーザーとして管理画面(マネジメントコンソール)にログインし、AWSの操作を行うよ。
IAMグループは、IAMユーザーをグループで管理するもの。業務や部署ごとにグループを作成するよ。
IAMロールは、AWSリソースに一時的な権限を与えるもの。IAMユーザーは永続的な権限だけど、IAMロールは一時的な権限だよ。
例えば、Amazon EC2とAmazon RDSがあるとする。Amazon EC2からAmazon RDSにアクセスしたいけれど、最初は権限がないのでアクセスできない。そこで、Amazon EC2にAmazon RDSへのアクセス権限を有したIAMロールを割り当てると、一時的にアクセスできるようになるよ。
IAMポリシーは、どのような権限を与えるかを定義するもの。
IAMポリシーをIAMユーザー、IAMグループ、IAMロールに割り当てることで、特定の操作を許可または拒否するよ。
AWS IAMのベストプラクティス
AWS IAMでセキュリティを高めるためには、IAMユーザー、IAMグループ、IAMロール、IAMポリシーに適切な設定をすることが求められる。適切な設定をする際、AWS IAMのベストプラクティスが参考になるよ。
POINT
01
ルートユーザーの使用を制限する
ルートユーザーは、AWSアカウントのこと。
ルートユーザーは、AWSアカウント内の全てのAWSリソースに対する、全ての操作権限を持っているよ。何でもできる神様のような存在で、権限が大きい分、乗っ取りや操作ミスによる損失も多きくなってしまう。そのため、ルートユーザーはできるだけ使わないことが望ましい。
AWSの操作をする際は、ルートユーザーではなく、IAMユーザーで行うようにするよ。
POINT
02
ルートユーザーを監視する
ルートユーザーの操作は、操作履歴(ログ)を見て監視する。
意図せずルートユーザーが使用されたり、不審な動きをしたら、すぐに分かるようにしておくよ。
POINT
03
1人1つのIAMユーザーを作る
1つのIAMユーザーを、複数人で使うことは控える。
1人のエンジニアに対して、必ず１つのIAMユーザーを割り振るようにする。そうすることで、誰が何をしたのか分からなくなることを防ぐよ。
POINT
04
パスワードは複雑にする
ルートユーザーやIAMユーザーがログイン時に使うパスワードは、英字や数字を混ぜて分かりにくく設定し、定期的に変更するようにする。
万が一パスワードが漏洩しても、定期的に変えるようにすれば、一定期間後に盗まれたパスワードが使えなくなる算段だよ。
加えて、不要なパスワードは削除すると尚良いよ。
POINT
05
MFAを有効化する
MFA(Multi-Factor Authentication)は、多要素認証のこと。多要素認証は、複数の要素で認証を行うことだよ。
例えば、パスワードの入力後にスマホに送られた番号の入力を求めるなどして、2つの要素で認証するよ。このようにして、本人でしかログインできない認証を作ることができる。
ルートユーザーは、必ずMFAを有効にすることが求められる。可能であれば、IAMユーザーもMFAを有効にすることが望ましいよ。
POINT
06
最小限の権限を与える
権限は沢山あったほうが、確かに便利で良い。でも、権限を与えれば与えるほど、誰が何をしたのかが分かりにくくなり、情報漏洩や誤操作が発生する可能性が高まってしまう。
そのため、必要な分だけの権限を与えるようにしたほうが良いよ。
POINT
07
グループ管理にIAMグループを使う
IAMポリシーは、IAMユーザーではなくIAMグループに割り当てるようにするよ。
仮に、１つのIAMグループの中に50人のIAMユーザーがいるとする。IAMグループ内の操作権限を更新したい場合、IAMユーザーにIAMポリシーが割り当てられていると、変更を50回行わなければならなくなってしまう。1人1人更新していくのは非常に手間で、更新漏れが起こりかねない。
そのため、IAMポリシーはIAMグループに割り当てておくよ。そうすれば、IAMグループ内にIAMユーザーが何人いても、更新はIAMグループに対する1回で済ませることができる。
もっと見る
ルートユーザーのみ可能な操作
ルートユーザーはできるだけ使わないことが原則だけど、ルートユーザーのみ可能な操作をする場合は使わざるを得ない。ルートユーザーのみ可能な操作を、下にまとめているよ。これらを行う場合のみルートユーザーを使い、それ以外の操作はIAMユーザーから行うようにするよ。
応用
- IAMポリシーの書き方
- IAMポリシーは、JSON(JavaScript Object Notation)で書く。JSONは、JavaScriptというプログラミング言語を模倣した書き方のこと。
IAMポリシーのサンプルコードはこちら。Versionは、IAMポリシーの名前のこと。ここには作成日を書く場合が多いよ。
Statementの中にあるEffectは、許可または拒否を定義するところ。許可する場合はAllowと書き、拒否する場合はDenyと書く。
Statementの中にあるActionは、どのような操作かを定義するところ。今回は、Amazon S3にデータ(オブジェクト)を登録すること、と書いているよ。
Statementの中にあるResourceは、何に対してかを定義するところ。今回は、example_bucketと書いているよ。
もしActionやResourceに*と書かれていたら、全てという意味になる。
Conditionは条件を定義するところ。例では、指定するIPアドレスを除くNotIpAddressが条件。
このIAMポリシーを適用すると、12.146.32.5/24を除き、Amazon S3のexample_bucketにデータを登録することができるようになるよ。
- クロスアカウントアクセス
企業の中で使われるAWSアカウントは、必ず1つとは限りらない。事業拡大や増員に伴い、複数のAWSアカウントを使って管理することがあるよ。
そういった場合、異なるAWSアカウントが所持するAWSリソースを操作するために、AWSアカウントを毎回切り替えるのは手間になる。そこで役に立つ、クロスアカウントアクセスという機能があるよ。
クロスアカウントアクセスは、異なるAWSアカウントのAWSリソースにアクセスするもの。下はクロスアカウントアクセスの例だよ。AWSアカウント①から、AWSアカウント②が所持するAWSリソースにアクセスできるよう権限を与えるとする。これを実現するには、信頼できる相手にIAMユーザー①を指定するIAMロールを、IAMユーザー②で作成する。
次に、それを組み込んだIAMポリシーをIAMユーザー①に適用する。このように設定することで、IAMユーザー①から、IAMユーザー②が所持するAWSリソースにアクセスすることができるよ。
- IDフェデレーション
Windowsは、Microsoft社が作ったデスクトップ向けのOSのこと。それと同じようなものに、Windows Serverというものがある。Windows Serverは、Microsoft社が作ったサーバー向けのOSのこと。
IDC Japanの調査によると、国内のサーバー向けOS市場の50％以上を、Windows Serverが占めている。サーバー向けのOSの半分以上はWindows Serverが使われていることになるので、非常に人気が高いものであるといえる。
Windows Serverが選ばれる理由として、導入が容易である、Microsoft製品をサポートしている、AD(Active Directory)という機能がある点が挙げられる。ADは、オンプレのリソースやアカウントを管理するもの。管理者はADにより、PC、プリンター、データ、ユーザー、アクセス権限などを管理することができるよ。
AWSの使用を考えている企業が、既にADを使って管理している場合、AWS IAMで管理する仕組みを作り直すのは時間が掛かる。そこで、IDフェデレーションを使えば、作り直す手間を無くすことができるよ。
IDフェデレーションは、異なる管理システムのIDを連携させるもの。IDフェデレーションにより、既存のADを使って、AWSにアクセスすることができます。- WEB IDフェデレーション
- 従業員が増えていくにつれ、アカウント管理作業に費やす労力も増えていく。例えば、Googleアカウント、Twitterアカウント、 IAMユーザーの3つを従業員が入社する度に作成しなければならない場合、管理者の負担が大きくなってしまいまう。
そういった場合、WEB IDフェデレーションが役に立つよ。WEB IDフェデレーションを使えば、ソーシャルIDプロバイダー(Google、Twitter、Facebookなどのアカウント)でAWSにアクセスすることができる。使い慣れたアカウントでAWSにログインしたい場合、便利な機能になるよ。 - AWS IAM Access Analyzer
- AWS IAM Access Analyzerは、不要に外部へ公開されていないかrを確認するもの。AWSリソースに付与されているIAMポリシーを監視して、信頼できない相手からアクセスされる可能性を検出する。
仮に、Aアカウントのみアクセスできるよう、エンジニアがIAMポリシーを設定をしたとする。しかし、エンジニアが気づいていない設定の漏れがあり、実はBアカウントからもアクセスできる状態になってしまった。
AWS IAM Access Analyzerから確認すれば、AアカウントとBアカウントからアクセスできることが一目瞭然になる。エンジニアは設定の誤りに気づいて、正しくIAMポリシーを修正することができるよ。