こんにちは、カスタマー・サポート課のマツシタです。
AWSアカウントの特にrootアカウントは多要素認証（MFA）を設定することが強く推奨されています。ただ、多要素認証を設定するだけで安全と言えるでしょうか？
今日はAWSアカウント運用のセキュリティのさらなる強化を考えてみたいと思います。
多要素認証に今、求められているもの
多要素認証を設定しない場合、AWSアカウント発行時に設定したメールアドレス（＝rootアカウント）とパスワードだけで最高権限でAWSアカウントにアクセスできてしまいます。多要素認証を設定すると、それ加えて、6桁の数字の認証コード（30秒ごとに更新されるワンタイムパスワード）が求められます。なので、外部から悪意のあるアクセス防止という観点では、セキュリティ強度を高めています。
しかし、最近よく指摘されるのは内部犯による不正侵入の可能性です。”一人”の悪意ある人によりAWSアカウントに不正アクセスされてしまう可能性がないかという課題を問われることが増えてきました。「rootアカウントとそのパスワードを知ることができる人」と「多要素認証の認証コード発行できる人」を分けることができれば、その課題は解決できます。そして、そのような運用が求められていると感じています。
多要素認証の選択肢
多要素認証用のツールの選択肢はハードウェアとソフトウェアの2種類に分けられます。ハードウェアにはカードタイプとキーホルダータイプがあります。詳しくは弊社ブログ「AWSのハードウェアMFA」をご参照ください。ソフトウェアは仮想多要素認証、ヴァーチャルMFAなどという呼ばれ方もします。最近は、様々な利便性からソフトウェアタイプの方が使われる機会が増えています。
多要素認証ソフトウェアはさらにいくつかのタイプに分類できます。広く使われているGoogle Authenticatorなどに代表されるスマホアプリタイプは、情報をデバイス（＝スマホ）に保有します。Authyなどに代表されるスマホでもPCでも使えるタイプは、情報をクラウド（SaaS）上に保有します。
個人で使う分にはこのどちらかのタイプが非常に便利です。ご参考までに、私自身はそれらのそれぞれの利便性を肌で感じるために、会社個人検証AWSアカウントはAuthyで、個人契約のAWSアカウントDuo Mobile（スマホアプリタイプ）で別々に多要素認証の設定を行っています。
先日OpsJAWS Meetup #8でローカルのWindows上で動作するWinAuthというソフトウェアを知りました。WinAuthの特徴は2つです。
WinAuthは認証サービスの部分ではGoogle Authenticatorと同様の仕様のロジックを使っております。Windows上で動作できるようにしたソフトウェアです。
セキュリティレベルでいうと、Windows上でAndroidアプリを動かすためのエミュレーターを通してGoogle Autheticatorを使うのと変わりありません。ただ、それよりも遥かに簡単だと感じられます。
特定の数名が操作するのではなく、10名以上が操作することを考えると、できるだけシンプルな構成で簡単な手順であることも大切な選択条件となります。
事例
構成概要
ここからは、WinAuthを使って運用している弊社の例を紹介します。
1つのAWSアカウントがあります。このアカウントには情報システム担当以外のスタッフは厳しい制限下でしかアクセスできません。ここにEC2インスタンス（Windows Server）をローンチします。このインスタンスのOSには社内では情報システム責任者以外のスタッフはログインできません。ただし、社外の業務委託先担当が、特定のIPアドレスからのアクセスに限り一定の制限下でアクセスできます。
このAWSアカウント上にローンチされたEC2インスタンスにWinAuthをインストールし、他のAWSアカウントの多要素認証設定情報を格納します。先に説明したSaaSタイプのサービスと同様に、設定情報はクラウド上ではあります。しかし、SaaSサービス上ではなく、クラウド上のインスタンスの中なのでセキュリテリィレベルの高さは異なります。
SaaSタイプのサービスへのアクセス制限が主にID・パスワードであるのに比べ、AWSのセキュリティグループなどの設定でIPアドレスやアクセスポートを適切に設定し、セキュリティレベルを上げることができます。まとめると以下のようになります。
| 担当 | マネージメントコンソールへの アクセス | EC2インスタンスへの ログイン |
|---|---|---|
| 弊社スタッフ全般 | 厳しい制限あり | 不可 |
| 情報システム | Full Access | Full Access |
| 外部委託先 | 不可 | 厳しい制限あり |
一人の操作でrootアカウントに入ることができるのは情報システム責任者のみです。また、AWSの操作はCloud Trailで、Windows Server（EC2インスタンス）上の操作はVistaraという証跡取得・管理ツールを使って、情報システム責任者の操作も完全に証跡を取得、保存しています。
弊社内に悪意を持って不正アクセスを試みるスタッフはいないと信じていますが、万が一にそのようなスタッフがいても、不正アクセス自体が非常に難しい状態であります。それでも、不正アクセスを試みようと各種ツールの設定を修正していかないと不正アクセスできません。しかし、その修正は構成・設定の全体像をかなり理解していないと難しいので、設定修正を試行錯誤している段階で検出できるような想定です。
運用の利便性
それだけ堅牢な設定を施したことで運用の利便性を心配される方もいらっしゃるかもしれません。そのあたりも、少し紹介させていただきます。
弊社では業務ワークフローの多くをQuestetra BPMで管理していますが、rootアカウントでのアクセス時の認証コード発行もそれに含まれます。
rootアカウントでアクセスしたい人はQuestetra BPMで申請を上げ、その申請内容に問題ないと承認された場合には、外部委託先との連携用のBacklogに課題が起票されます。続いて、本人と外部委託先にslackのDirect Messageで暗証番号が通知されます。外部委託先はBacklog起票とslack DM通知をもって、WinAuthのインストールされたインスタンスにログインします。認証コード発行の準備を完了した後に、申請者に電話し、暗証番号で本人確認を行った後に、認証コードを伝えます。これで申請者は指定したAWSアカウントにrootアカウントでアクセスできます。
申請者の手順
その他の運用面の配慮
EC2インスタンスは必要な場合のみ、つまりQuestetra BPMの申請をトリガーとして、Cloud Automatorで自動で起動と停止を行います。（内部的にはQuestetra BPMからAmazon SQSを経由してCloud Automatorジョブを実行させます。）
WinAuthの設定情報はEC2インスタンスのOS上にファイルとしてあります。外部委託先のオペレーターがそのファイルをダウンロードできないように設定されております。また、そのファイルをスマートフォンなどで画像として取得できないように、外部委託先ではデスクへのスマートフォンなどの持ち込みを禁止しています。
まとめ
サーバーワークスでは、お客様の大切なAWS環境を預かる上で、セキュリティと運用の両面での最適化を考え、このような構成で現在、運用しています。
情報システム管理はISMSにポリシーに従った運用で水準以上の安全性は確保していると考えています。それでもまだ、不正アクセスを試みようとする行為への、監視と通知の仕組みを検討し、さらに安全性向上の対策を引き続き考えていきたいと思っています。
