AWSのリソースやアカウントの管理を濃厚に語ったOpsJAWS

アスキー 2016年11月15日(火)08時00分配信

9月27日、目黒のAWSJオフィスにおいて第8回目となるOpsJAWSが開催された。「運用」に敏感に反応する人たちを対象とするOpsJAWSの今回のテーマは「アカウント管理」。タグ付けやMFAの運用、SSOのススメ、アカウント分割などについてディープなLTが披露された。

誤操作防止のタグ付け活用を味澤さんが語る

 冒頭、「背伸びをしないAWSタグ付け」をテーマにLTを披露したのは、日本ユニシス<8056>でAWSの案件支援を担当している味澤健司さん。AWSのリソースに付与できるタグを活用することで、プロジェクトごとのリソースを適切に管理し、誤操作がないようしたいというのがLTの趣旨だ。

IM
日本ユニシス<8056>の味澤健司さん

 同社の案件支援では、影響の狭そうなシステムからAWSに移行し、徐々に他システムを移行したいという依頼が舞い込んでくる多いという。しかし、リソース名に手作業でプレフィックスを付けてプロジェクトを識別すると、誤って隣のシステムをいじって誤操作するのではないかと不安があった。「アカウントはお客様やプロジェクト単位で作っているし、IAMなどで権限は分けているものの、他システムを載せることを意識していないがために誤操作の心配がある」(味澤さん)。そこで検討したのが、AWSの各リソースに付与できるタグ。プロジェクトごとにタグを付与し、誤操作を防げるかもしれないと味澤さんは考えた。

 タグ付けをまとめて行なうにはAWSのコンソールの「タグエディタ」を使うのが便利。タグエディタを利用し、対象のリソースを指定し、キーとタグを入力すれば、複数のリソースにまとめてタグを付与できる。いったんタグを付与すれば、検索によってリソースを指定し、特定のタグがついているリソースを表示・操作できる。また、IAMのポリシーにコンディションを記述することも可能だ。

IM
マネジメントコンソールを使えばリソースの検索も容易

 もちろん、タグですべてが解決できればよいが、課題もある。たとえば、タグに対応していないリソースの場合は、これまで通りリソースの命名規則で対応しなければならない。また、IAMのポリシーだけでタグによる制限を実現するのは難しく、結果としてJSONが複雑になってしまうのも弱点もある。

 ちなみにAWS CLIのオプションを使うことで、タグが指定できるという。特定のタグに対してFliterやQueryのオプションを使ったり、リソース名の部分一致させることも可能。味澤さんは、「誤操作を簡単に防ぎたいと思ったらタグは便利。でも、細かい作り込みが必要なのであれば、ツールを使って自動化するのが理想」と語って、LTをまとめた。

MFAの安全・安心な運用をスカイアーチの星さんが語る

 続いて「組織利用におけるMFA管理方法を考える」というテーマで講演したのはスカイアーチネットワークスの星幸平さん。「MFAの運用に関する情報が意外とWebにない」(星さん)とのことで、全特権を有する特権アカウントを安全に守るため、MFA(Multi Factor Authentication)をどのように運用すべきかというのが大きなテーマだ。

IM
スカイアーチネットワークスの星幸平さん

 MFAはAWSのセキュリティを強化する多要素認証の仕組みで、時刻を用いたワンタイムパスワードが利用できる。現状、ルートの特権アカウントはIDとパスワードにMFAを組み合わせることしか強化する手段がない。そのため、AWSを安全に利用するためには、特権アカウントのアクセスキーを削除し、MFAで保護し、IAMで権限を使い分けるのがベストプラクティスになる。「IAMでできないことは契約の変更や請求周りくらいなので、普段の運用では特権アカウントを封印しても普段の運用で困ることはない」と星氏は指摘する。

 とはいえ、組織内でのアカウントが複数になったり、プロジェクトごとにアカウントが別れていたり、MFA管理方法がアカウントごとに違うと、管理の手間が大きくなる懸念がある。そのため、スカイアーチではMFAをセキュアかつ、効率的に運用できる方策を模索したという。

 要件としては、まず決められた人だけがMFAを利用できるようにすること。また、利便性を確保するため、リモートで利用できるようにすること。さらに可用性と信頼性を重視し、なるべくMFAの再設定の手間がないようにしたいという点が挙げられた。

 現状、MFAはハードウェアMFA、ソフトウェア型の仮想MFAのほか、プレビュー版としてSMS MFAが存在する。まず物理的な盗難や置き忘れ、故障などの可能性があるハードウェアMFAはセキュリティの高い場所で選定して保管し、高温多湿やモノの出入りが多い苛酷な場所は避けた方がよい。カード型は同期切れという仕様上の問題があり、「早い時は1~2ヶ月で同期切れになるので、定期的にログインして再同期する必要がある」と星氏は語る。また、物理デバイスという性質上、リモートアクセスや可用性、信頼性を担保するのは難しい。

IM
キーホルダーやカード型のハードウェアMFAのほか、スマートフォンやPCで使える仮想MFAなどさまざま

 次にスマートフォンに導入するタイプの仮想MFAだが、Google AuthenticatorやAutryなどがある。こちらは1つのハードウェアで複数のアカウント管理ができ、スマートフォンを使えば同期の問題もクリアされる。アプリケーションは無料だが、普段使いのスマホに入れるのはリスキーなので、やはりハードウェアMFAと同じように保管することが推奨されるという。ただ、「ハードウェアMFAに比べて要件は合いそうだが、そもそもスマートフォンがリモートアクセスを想定していないので、そこは問題」(星氏)と語る。

 仮想MFAはさまざまなプラットフォームで利用できるのが大きい。同期の問題もなく、アプリケーション自体は無償。「MFAの実体がファイル形式なので、利用権限が細かくできる。バックアップも可能ファイルサイズも小さいので、ストレージの保存もしやすい」(星氏)。今回、スカイアーチではWinAuthを採用し、Windows PCで運用することにした。MFAの保管場所はRAID対応の基幹ストレージに入れておき、VPN経由でWinAuthを起動。トークン発行することで、ルートアカウントにログインできるという。なお、設定ファイルはAmazon S3にあるので、有事の時はS3から復元できるという。

IM
スカイアーチで実践したWinAuthでのMFAの運用

 ハードウェアMFAに比べたメリットは、まず同期切れがなくなったこと。また、リモートアクセスは思いのほか便利だが、セキュリティも重要になるので、リモート端末のセキュリティ対策は手を抜けない。総じて、MFAデバイスの管理から解放されたが、その代わりアクセス権の管理や構成の運用が必要になったという感想だ。最後、星さんは、「仮想MFAが必ずしも最適解というわけではないので、組織ごとの要件を理解して適切な運用方法を選定する必要がある」という。

SSOを実現するOneLoginのメリット

 続いて登壇したサーバーワークス情報システムの宮澤慶さんは、「AWSをより安全に使うためのID管理」を語った。

IM
サーバーワークス情報システムの宮澤慶さん

 宮澤さんは、さまざまなデバイスからクラウドサービスを使える一方、複数のクラウドを使うと管理が煩雑になるとID管理の課題を語る。また、複数のアカウントで共通のポリシーが適用できないというのも課題の1つだ。

 これを解決するのがサーバーワークスが導入している「OneLogin」だ。OneLoginでは1つのIDで複数のサービスをログインできるSSOを実現できるほか、共通のパスワードポリシーを適用できる。エンタープライズ環境で導入の多いActive Directryとの同期も可能で、LDAPやGoogle Apps、Workdayなどとも連携する。コンプライアンス面でも有効ですべてのユーザーの変更とアクティビティを記録し、後追いで監査することも可能。さらに、CSVをインポートすることで、BIツールでの可視化もできる。

 OneLoginではID・パスワードの代理入力ができるほか、ID連携プロトコルであるSAMLを用いたSSOが可能になる。OneLogin経由でAWSにログインすると、SAML用のIAM Roleを利用してユーザーがコンソールを利用できるため、CloudTrailで認証証跡をユーザー別に簡単にとることができる。裏では相当複雑なシーケンスになっており、認証や認可の要求、権限確認、操作記録などが各コンポーネント間で行き交っているという。

IM
OneLoginの背後でSAML認証のための複雑なシーケンスが動いている

 OneLoginでは運用する側も恩恵を受けられ、ユーザー側もID・パスワードを知らないで使える。とはいえ、OneLoginのアカウントが漏えいすると、すべてのサービスが利用できてしまうため、多要素認証の導入が必須だという。宮澤さんは「MFAで認証を強化するのはもちろん大事。それに加え、うちの会社はOneLoginでSSO環境を実現し、認証をシンプルにした上で、そのアカウントをMFAで守るということをやっている」(宮澤さん)。

AWSアカウントを分割してもデメリットはあまりない

 「AWSアカウントを複数に分けるメリットとデメリット」というタイトルで最後に登壇したのは、AWSJのパートナーソリューションアーキテクトの小梁川貴史さん。もともと4年くらいはユーザーとしてAWSを利用していた立場で、JAWS開催のタイミングがAWSに入社してから満1年になるという。

IM
AWSJ パートナーソリューションアーキテクト 小梁川貴史さん

 AWSを使ってパートナーと開発やプロダクションを行なう場合、1つのアカウントだとなにかと不都合が多い。「開発環境には広い権限を与えないと必要なロールの検証ができないし、IAMでロールをいちいち付与するのは面倒。でも、プロダクションは誤操作を防ぐために権限を絞りたいけど、正社員は権限を持たせ、協力会社は参照のみにしたいというケースも多い」と小梁川さんは語る。

 また、1つのアカウントで複数のプロジェクトを抱えると、他のEC2やSecurity Groupが見えてしまうため、誤操作の可能性もあるし、課金の按分も面倒になる。さらにサポートやメンテナンス通知に関しても、複数のプロジェクトが混在すると煩雑になる。その他、LambdaやAPI Gatewayなどアカウント当たりのスロットやリクエストが決まっているサービスの場合は、性能面での制約につながってしまう。こうしたデメリットを考えると、アカウントを分けるという考え方も取り入れたほうがよいようだ。

 最近ではアカウントをまたいだ運用も楽になっている。たとえば、AMI<3773>(Amazon Machine Image)に関しては、以前はアカウント単位で作成しなければならなかったが、今ではアカウントをまたいだコピー機能が利用できるようになっている。また、DBに関しても以前はダンプから複製しなければならなかったが、現在では他のアカウントからスナップショットを複製できるようになった。「アカウントを複数またぐことによって生じていたデメリットは、昨今解消されつつある」と小梁川さんはアピールする。

IM
アカウントを超える機能が充実してきている

 また、コストに関しても「Consolidated Billing(一括請求)」という概念が導入されており、支払いアカウントを1つにまとめることができる。経費処理的には1回の処理、1枚の請求書で済み、複数にまとめるとボリュームディスカウントのしきい値を超えられるので、コストメリットも大きい。RI(Reserved Instance)に関しても、同一リージョン、AZ、サイズという条件で転用することが可能になるため、損することはないという。

 一方でデメリットもある。まずは複数のアカウントがまとめられて平均値化されるので、RIの割引なども含め、アカウントごとの厳密なコスト換算がやりにくくなること。また、ルートアカウントが多数できることになるので、運用や権限委譲のルールを厳密に統制する必要がある。そのため、各アカウントのオーナーは責任を持ってIAMを運用しなければならない。

 個人的には分割推進派だという小梁川さんは、実際の運用イメージを示した。まずチーム内で開発用とプロダクション用でアカウントを分割しつつ、支払いアカウントを統合。さらに監査用のアカウントを作り、CloudTrailで取得したログなどをまとめてS3バケットに収めるのがオススメだ。このやり方だと、「会社の監査のやり方が変わっても、バケットは1つなので、チェックのやり方を1箇所変えればいい」(小梁川さん)というメリットもある。

IM
アカウント分割の利用イメージ

 小梁川さんは、「アカウントを割ることは権限分割の第一歩。もちろんIAMでできることも多いけど、共有アカウントの中で権限を変えるより、アカウント自体を分けることで、権限を明確にし、チーム間の依存をなくすことができる。セキュリティの第一歩ということで、アカウントを分割することを検討してはいかがでしょうか?」と語り、将来的なアカウント分割の検討や分割時のコスト換算に関する情報収集、タグ付けの徹底などをアピールし、セッションを終えた。

 このように夢物語だけではないAWSの運用現場での苦労や工夫が満載のOpsJAWS。都内でも特に活発に活動しているユーザーグループの1つなので、興味があるユーザーはぜひ参加してもらいたい。

アスキー
もっと見る もっと見る

【あわせて読む】

    最終更新: 2016年11月15日(火)08時00分

    【関連ニュース】

    【コメント】

    • ※コメントは個人の見解であり、記事提供社と関係はありません。

    【あなたにおススメ】