クラウドのメリットの一つに、システム開発のアジリティを向上できるといったものがあります。アジリティを向上させるには、開発者が好きなときに好きなように様々な実験を素早く実施できることが非常に重要となってきます。
特にマネージド型サービスを活用したサーバレスなアーキテクチャで開発しようとすると頻繁にAWS 上にリソースを作成しては実験するといったことを自由にできたほうが良いですよね。
そのようなときに単一のAWS アカウントを開発者全体で使い回すと、リソース名がかぶったり、他人の実験用リソースに引きづられてうまく動かなかったりと調整や切り分けが大変で素早く実験するというモチベーションが下がる場合があります。
そう考えると、AWS 上のシステム開発においては、開発グループ全体で一つのAWS アカウントのみを利用するよりは、開発者ごとに個別にAWS アカウントを発行し、各開発者は自由に自分専用のAWS アカウントを利用できるといった構成が良いと思います。
そうなると次に考えなければならないのは、そのアカウントの統制をどのようにすべきかです。この考え方で行くと、50 人開発者がいれば50個のアカウントを管理しなければならず、例えば、最低限以下のようなことを考えて50個のアカウントに対してコントロールしないといけません。
- コストの高いリソースを際限なく利用されてしまい開発コストが無駄に高くなる
- アクセスキー流出による不正アクセスを抑える
ただし、統制をかけすぎても素早く自由に実験するというメリットを阻害してしまうかもしれません。
AWS ではこのような問題に対応するためにAWS Organizations を利用することができます。AWS Organizations には複数アカウントを効率的に管理して統制かけることができる機能が用意されています。また統制をガチガチにかけすぎずにゆるく設定して、その内側であれば自由にAWS を利用しても良いですよといった考え方を適用することもできます。これをガードレールというように呼んでいます。これにより個人の裁量に任せつつ、これ以上進むと危険であるというガードレールを設置して安全性を高めるという考え方です。
AWS Organizations の機能をまとめると以下のようになります。
Organizations のSCP やConfig などを活用してガードレールを設置することができます。
Organizations を利用することで、例えば以下のような構成で開発者それぞれに開発用AWS アカウントを割り当ててSCP でガードレールを設置しつつ縛りすぎない統制をかけながら各開発者が自由に自分専用のAWS アカウントで頻繁に実験をしながら開発を進めていくといったアカウントの全体構成を考えることができます。(この図はあくまで一例です。)
上記構成のポイントは、各開発者の認証情報を一元的に管理するための”認証アカウント” というAWS アカウントを用意し、開発者はまずこの認証アカウントにログインした後、自分用の開発アカウントへIAM ロールを使って切り替えるという構成としています。これにより認証周りの統制をかけ、不正アクセスのリスクを減らすということができるようになります。
とくに、認証周りでは、開発者は開発環境にプログラムから利用する”アクセスキー” というIAM で管理される認証情報を設定しなければならない場合が多いです。
ただ、このアクセスキーが外部に流出してしまい、AWS アカウントに不正にアクセスされてしまうといった事故が、世の中で非常に頻発しています。
では、アクセスキーの流出事故が発生するリスクを抑えるにはどのように対応すれば良いでしょうか？
まず基本ですが、開発者一人一人が気をつけるというのも重要な点です。特にアクセスキーというのは単なる文字列であり、プログラムから利用することが前提なので、ファイルに保存したりすることでよく目についてしまうため、 認証情報であるという認識が薄れてしまうことが多々あります。
ウェブなどを調べていると、開発グループで利用しているSlack にアクセスキーを流して複数の開発者で共有していたら、知らないうちに流出していたなどの事例もあったりします。
よって、アクセスキーは認証情報であり、決して他人と共有したりして良いものではないという一人一人への教育と、一人一人が気をつけて扱うというのは大前提だと思います。ただ、やはり人が扱うものなので、うっかり漏れてしまうといったことは考えられないことではないです。特にアクセスキーは開発端末上で利用するといった利用方法になりますので漏れてしまうリスクはやはり高いと思います。
そこに対して、例えば、開発端末からのインターネットへのアクセスをガチガチに縛ってしまうなどの対策も考えられます(場合によっては、AWS 以外へのアクセスはすべて禁止してしまうなど) 。そうするとインターネットにアクセスキーが流出するリスクは下がりますが、100 % ではないですし、更に重要な開発のアジリティやスピードを妨げることになります。これをやったらそもそもクラウドを利用する価値がなくなってしまいかねません。
ではどうすればよいか？考えられる方法として、アクセスキー単体ではAWS アカウントにアクセスしても何も操作できないようにしてしまうという制限を加えてしまうということが考えられます。アクセスキー単体でアクセスできないということはすなわち、MFA（Multi-Factor Authentication = 多要素認証) を必須とする構成になります。
前置きが非常に長くなりましたが、本題がこれです。認証用アカウントでIAM ユーザの認証情報(マネージメントコンソール用のユーザ名/パスワードと、プログラム用のアクセスキー)を一元管理しつつ、各開発用アカウントにはMFA で認証されていないと一切アクセスできないように統制をかけるという方法を取るのが良いかと思います。
ただ、開発環境周りのMFA に関しては、アクセスキーによるアクセスにMFA を必須とするような構成を考えなければなりません。ここでは、上述したアカウント構成に対して、アクセスキーを利用したアクセスに対するMFA 必須の構成方法を記載していきたいと思います。
前置きが非常に長くなってしまったので、実際の設定方法は以下の記事に分けて記述しています。
以上です。