クラウド移行の構築作業フェーズでよくあるミスとその対処法：はじめてのクラウド導入“これ“に注意（2/2 ページ）

[折笠丈侍，ITmedia]

クラウドならではの「認証と権限設定」を理解しよう

　クラウドサービスは、一般的にサービスやリソースを複数のユーザーでシェアするため、セキュリティの実装が重要だ。AWSではIAM（Identity＆Access Management）と呼ばれるサービスで認証と権限付与を各サービスから独立させ、仮に認証情報の漏えいが発生してもリスクを最小に抑えられる。

　これはクラウドならではの考え方だ。オンプレミスの設計では、データベースを参照するアプリケーションの内部にデータベースの認証情報を権限と一緒にハードコーディング（埋め込む）する場合がある。アプリケーションにデータベースの認証を埋め込めば、セットアップの作業が一回で済み便利に見えるが、アプリケーション側で持っているデータベース認証情報やアクセス権限が洩れれば、データベース側にもリスクが拡大する。

　AWSのIAMは、アプリケーション側にデータベースを利用する認証情報や権限を永続的に持たせるのではなく、あらかじめ「IAMロール」というサービス上でシークレット情報と権限の大きさを別個に定義し、かつ権限を一時的なトークンとして払い出すことでリスクを最小化する仕組みだ。

　このIAMロールを正しく割り当てる作業を怠ると、「アプリケーションがデータベースを呼び出せない」「データベースを参照できても書き込む権限がない」「バックアップ格納先のストレージにアクセスできない」といった事が起こる。

　IAMを設計、利用する際は、レファレンスや実装事例を参照し、パートナーの支援などを受けるのが得策だ。

設計ミスで起こる「サービスにアクセスできない」を防ぐには

　パブリッククラウドというと、「外部に公開されたオープンな環境」というイメージがある。AWSはデフォルトでVPC （仮想専用領域）と呼ばれる外部からアクセスできないクローズドのリソース空間を最初に設け、その内部で安全にシステム運用する仕組みを持っている。

　VPCの内部に、オンプレミスで利用していない空きのプライベートアドレス帯を割り当てて必要なサブネットを構成し、次に仮想マシンやデータベースなどをサブネット内に配置してサブネットまたはサーバ単位ごとにファイアウォールを割り当てる。

　これらをAWSが用意するサービス用仮想ルーターのテーブルで設計していくが、このファイアウォールのフィルタリングルールやルーティングが正しく設計されないと、「AWSの外部・内部のサービスやサブネットに到達できない」などの事象が起こる。この点もオンプレミスと勝手が変わるため注意が必要だ。

図3　AWSクラウド内部のネットワーク設計例（出典：ソニービズネットワークス作成）

冗長設計は自前かサービスか　それぞれのメリットデメリットを理解しよう

　第2回で触れたように、クラウドサービスにおける仮想マシンに付与されるIPアドレスや仮想NIC上のMACアドレスは、デフォルトでは動的割り当てとなり値が変動する。オプションで固定できるが、自前で冗長構成を設計する場合は動作がクラウドサービス側の仕様に依存するため注意が必要だ。

　クラウドにおけるシステム連携は、サービス単位ごとのAPIで連携する分散型アーキテクチャとなる。モノリシックな密結合システムから移行する場合はアーキテクチャが変わるので注意しよう。また、オンプレミスで利用中のアプリケーションやミドルウェアのライセンスを持ち込む（BYOL：Bring Your Own Lisence）場合も、ライセンス発行元が定める利用制限などで、ライセンスの追加購入が発生して費用が増えるケースもあるため、事前の確認が欠かせない。

　さらに、冗長構成に取り組む際は「OSやミドルウェアが持つクラスタリングやフェイルオーバ機能、レプリケーション機能を組み合わせて自前で設計するのか」「クラウドサービス側のマネージドサービスで冗長化するのか」についても、それぞれのメリット、デメリットを理解しなければならない。

　前者はコストを抑えられるが、設計に必要なスキルと運用工数が課題だ。後者はランニングコストがやや増加するが、比較的容易なステップで冗長構成をセットアップでき、パッチングやレプリケーション、バックアップなどの運用工数をクラウドサービス側にオフロードできる。障害時のフェイルオーバの挙動の安定性を担保しやすく、トラブル時のサポートも受けやすくなる。

図4　オンプレミス／IaaS／SaaS（マネージドサービス）の責任分界図（出典：ソニービズネットワークス作成）

運用に求められる「DevSecOps」とは？　

　移行シナリオで最も多く採用される「リホスト」だが、ありがちなケースが「オンプレミスの構成をそのままクラウドに適用し、その後も見直しをかけずに運用する」ことだ。クラウド移行は組織や担当者にとって一大イベントであるがゆえに、移行直後に「その後の運用」を見据えた設計に手が回らないのだ。

　しかし、クラウドにおける柔軟な設計変更や追加といったメリットを享受するためには、運用の最適化が欠かせない。また、クラウドであればモニタリングやロギングなどのセキュリティ／コンプライアンス周りの対応サービスが無料または低コストで利用でき、サービスも豊富に用意されていることが多い。

　AWSは20を超えるセキュリティとモニタリングのサービスを持ち、それらを適用してリソースの偏りやセキュリティリスクを迅速に設計に反映できる。さらに、運用の自動化で工数を下げ、システム全体のパフォーマンスや可用性、セキュリティ、運用管理の精度を継続的に高められる。

　クラウド活用のメリットを享受するには、このような「Dev」（開発）、「Sec」（セキュリティ）「Ops」（運用）に基づいた運用体制を目指すことが重要だ。

　第4回はクラウド移行後の「クラウド設計・構築フェーズ」におけるつまずきポイントを解説する。