AWSを利用したシステム基盤の標準化検討
アマゾン ウェブ サービス（AWS）を初めとするクラウドの利用が加速しています。その背景は、利用者自らがブラウザ経由で提供されるクラウド管理コンソールから、チュートリアルに従い設定値を投入するだけで、簡単に利用できてしまう事にあります。これはクラウド利用における最大の利点であり、迅速なシステム基盤の構築を要求するユーザには絶好のメリットを享受できます。
しかしながら、簡単に構築できてしまう反面、企業内で様々な担当者がシステム部の預かり知らない管理外の、いわゆる「野良AWS環境」が意図せず稼働する事が多々あり、これらは外部からのセキュリティの脅威や、情報流出等のリスクを考慮されない環境となります。クラウド環境を安全に利用するために、企業のセキュリティ基準に則ったセキュリティ対策、また複数のシステムが稼働するために最適化された環境、一方で、利用者への自由度はある程度与える、つまりガバナンスとアジリティを両立させた標準化されたシステム基盤を用意し全社向けに提供すべきです。
本記事では、その標準化検討のプロセスや検討観点について解説していきます。
標準化の目的
何を目的として標準化するのか？標準化に向けた検討の拠り所となる道しるべを定める必要があると考えます。つまり、標準化により誰にどのような効果やメリットを提供するのかを明確にする必要があり、この目的の明確化が最重要となってきます。
標準化の目的（例）
- 個々のシステムの要求に応じ、迅速に環境を払いだし開発スピードの向上に寄与する
- 統一されたセキュリティ基準に沿ったシステムの展開によるセキュリティ事故の未然防止
- 最低限のセキュリティ基準は満たしながら、クラウドの特性を十分に活用すべく、アプリケーション開発に有効となるPaaS機能の開放（個別システムにクラウドサービス利用の自由度を与える）
- 個々のシステム個別で考えてきた、同種の機能を共通機能として実装し、個別システム開発の負荷を軽減する
- 個々のシステムで共通項となる運用を一元的に管理し、運用効率化を実現すると共に運用品質を向上させる
- 既存システムからの確実で迅速な移行
標準化の対象箇所
標準化対象の範囲を定義し、個々のシステムで開発する範囲、標準化基盤で提供する範囲を明確にする必要があります。例えば、システムの例としてOS（一部）・サーバ・ネットワーク・非機能・セキュリティ・運用を標準化対象とする場合のシステム構成概要は下図のようなものが考えられます。
標準化検討の観点
- インフラ基盤
原則、複数企業が同一環境を共同利用するマルチテナント環境と認識し、クラウドサービスが提供する環境分離機能やデータ分離、認可機能等の活用を検討し、資産の混在を防止する事が重要です。
| 検討項目 | 検討内容 |
|---|---|
| アカウント管理 | 契約単位となるアカウントの適用範囲や方法。 また、アカウント間の連携を意識したアカウント構成方法 |
| 認証、認可 | クラウドサービス管理コンソールへ接続する際の認証、認可の方法。運用チーム体制（どのチームが何の運用をするのか）と、認可は密に連携するため、詳細に検討する必要がある。また、外部委託先の開発ベンダーに対する認証、認可の方法も必要。利用者が既存で利用しているIDを利用し認証したい場合など、個別ケースも要検討。 |
| シークレットキー管理 | クラウドから提供するシークレットキー（クラウドサービスをAPIで操作）の管理方法 |
| システムランク定義 | 個別システムのシステム重要度に応じた可用性、拡張性定義や構成パターン。 また、個別システムにおける、本番、検証、開発環境の構成も意識して実施する |
| 提供サービス | クラウドが提供しているサービスを何処までユーザに標準化し開放するのか。ユーザに開放するサービスについてサービス利用時に情報漏洩の可能性等、 サービス仕様を確認、検証したうえで提供が必要 |
| 開発ガイドライン | 利用者（個別システム開発者）に提供する開発ガイドラインの作成。クラウドサービスの特徴、システム開発の流れ、設計・開発・運用のポイント、責任範囲等を解説する為の資料 |
- ネットワーク
インターネットとIN/OUTになる接続口を標準化基盤として提供するのか、各システムに委ねるのかを検討し、前者であれば、セキュリティ機能の適用を検討します。
| 検討項目 | 検討内容 |
|---|---|
| 個別システム内のサブネットの分割 | 個々のシステム内のネットワークセグメントの構成方法やセグメント間の通信制御方法 |
| 個別システム間のネットワークアクセス経路 | 個々のシステムどうしを接続するネットワークアクセス経路や通信制御方法 |
| 各社からのネットワークアクセス経路 | 利用者の各社から共通基盤にアクセスする際の接続パターンやネットワークアクセス経路 |
| 開発ベンダーのネットワークアクセス経路 | 利用者が個別システムの開発を外部開発ベンダーに委託した際の、開発ベンダーから共通基盤へのアクセス経路や通信制御方法 |
| インターネットから外部公開環境へのアクセス経路 | インターネットから個別システムにアクセスする際のネットワークアクセス経路や通信制御方法 |
| インターネットへのアクセス経路 | 個別システムがインターネットにアクセスする際のネットワークアクセス経路や通信制御方法 |
| ドメイン管理 | ドメインゾーンの管理方法や、インターネットからのシステムの名前解決、また外部ネットワークからの当システムの名前解決の方法 |
- セキュリティ
セキュリティポリシーに従い、標準化基盤では最低限のセキュリティ基準を満たし、利用者にセキュリティ対策を要求する箇所を明確にします。
| 検討項目 | 検討内容 |
|---|---|
| 改ざん検知 脆弱性診断 不正侵入検知（IDS/IPS） 特権ID管理（OSレイヤー） WAF |
検討のインプットとなるセキュリティ基準に従い、最低限遵守すべきベースラインを定め、セキュリティ対策の実装方法を検討。 また、当該セキュリティ対策機能を、各個別システムから利用するクラウド基盤の共通機能として提供する事も合わせて検討する |
| クラウドガバナンス機能 | 個別システム単位にクラウドアカウントを提供し、ある程度の操作自由度（設定許可権限）を与える場合、利用者が設定した内容が妥当か否かについて診断を検討する |
| ペネトレーションテスト | 個別システムに対しペネトレーションテストを提供する是非や方法を検討する |
- 非機能
受入想定の個別システムが個々に実装している非機能を整理し、標準化基盤として標準的に提供する非機能を見極めます。
| 検討項目 | 検討内容 |
|---|---|
| システムバックアップ | 個別システムで稼働しているシステムやデータ部分のバックアップ方式を検討する。 システムを停止できないケースが想定される為、システム静止点の取得方法を考慮しオンラインバックアップも合わせて検討する。 また、バックアップ取得時間やバックアップ世代数、保管日数等の個別システムの要求に応じ個別に設定できるように考慮が必要 |
| 遠隔地バックアップ | バックアップしたデータを遠隔地にバックアップする方法を検討する。 こちらも、バックアップ取得時間やバックアップ世代数、保管日数等の個別システムの要求に応じ個別に設定できるように考慮が必要 |
| BCP環境 | 個別システムが稼働しているリージョンの大規模障害を考慮し、他リージョンでシステムを継続する方法を検討。 また、BCP発動時のネットワーク経路の切替え方法についても合わせて検討が必要 |
| ログ取得、解析 | 個別システムが出力するログの集中管理の方法を検討する。 ログ保管期間、保管期限が過ぎたログの扱い、ログに対するアクセス権限も個別システムの要求に応じ個別に設定できるように考慮が必要 |
| 監視 | 個別システムの統合監視を検討する。 監視閾値、アラート先等の個別システムの要求に応じ個別に設定できるように考慮が必要 |
| ジョブ管理 | 個別システムの統合ジョブ管理を検討する。 ジョブ実行時間、ジョブフロー制御、ジョブ失敗時アラート等、個別システムの要求に応じ個別に設定できるように考慮が必要 |
| 鍵管理 | 個別システムの鍵管理を検討する。 鍵のローテンション間隔、鍵へのアクセス権限等は個別システムの要求に応じ個別に設定できるように考慮が必要 |
- 運用
運用項目を整理し、個別システムと標準化基盤の運用範囲の明確な定義します。
| 検討項目 | 検討内容 |
|---|---|
| アラート、障害対応 | 監視機能やクラウドサービスから通知されるアラート対する障害対応方法の検討する |
| コスト管理、請求管理 | 利用者のクラウド基盤利用料を把握し、共有機能を利用している利用者への利用料の按分方法等を検討する。 また、クラウドベンダーからの利用料請求から利用者への請求までのフローを検討する |
| 環境払い出し自動化 | 利用者からの環境利用申請に応じ、運用者が自動的に環境を提供する方法を検討する |
| CI/CD基盤の提供 | 個別システムのアプリケーション開発に必要となるビルド、テスト、デプロイ環境を提供する方法を検討する |
| クラウドリソースの長期契約によるコスト低減 | クラウドベンダーは長期利用によるディスカウントメニューを用意しているため、クラウド基盤としても長期利用の利用者に対し、利用料低減のアナウンスや長期利用者の把握方法について検討する |
| 構成管理、棚卸運用 | クラウド標準基盤のリソース、ユーザ情報を定期的に棚卸し、未使用のリソースやユーザに対する削除等の運用を検討する |
| 監査対応 | 監査人からの要求情報（ログ等）を提供できるように準備し、また監査人がリモートで環境を参照する場合に備え、読み取り権限のユーザ準備する事も検討する。 また、クラウドベンダーが準備する外部機関が提供するコンプライアンスレポートの利用者への提供方法を検討する |
| 新規クラウドサービス提供やクラウドサービスの機能追加、変更の追随 | クラウドベンダーが新規提供するサービスや、既に標準化されているサーバに対する機能検証を経て、クラウド基盤の標準サービスに適用するか否かを検討する |
| 各種運用フロー、運用手順化 | 上記、運用項目に対し利用者から依頼受付、作業、完了報告までの一覧の流れをフロー化し、運用員が定例作業を行えるように手順化する。また操作対象とクラウド管理コンソールは刻一刻と改修が実施されため、定期的な運用フローや手順書修正タイミングや方法をも検討する |
- 移行
既存システムからの移行パターンを整理、検証し、標準化基盤構成にマッチした移行方式の提供を検討します
| 検討項目 | 検討内容 |
|---|---|
| 既存環境からの移行 | 既存環境からの移行方法を確立、パターン化しシステムの特性に応じて選択し活用できる状態とする |
AWSアカウント管理
ここで、一つ目の検討項目となる“AWSアカウント管理”をピックアップし、具体的に検討したいと思います。
AWSの利用を開始する時にAWSアカウントを作成しますが、その際に「このアカウントって誰がするのか？」「どの環境用なのか？」などと考えた事はありませんでしょうか。
計画を建てずAWSアカウントを作成していくと、複雑でガバナンスが図れない構成となってしまう可能性が高いため、そうならないためにも、しっかり整理され、深くまで考え抜かれたAWSアカウント構成の検討が必要になってきます。
AWSアカウントの特徴
AWSアカウントはどういうものでしょうかまず、AWSアカウントその物の特徴を考えてみました。
- セキュリティにおける境界の単位
他のアカウントとのセキュリティの境界の役割を果たす（他のAWSアカウントの構成は見えないしアクセスできない） - AWS環境における分割単位
アカウント単位でAWSのさまざまなリソースを管理する - AWS課金における分割単位
AWSのサービスの利用における課金はAWSアカウントに対して行われる
検討観点からメリット・デメリットを考える
AWSアカウントを、どのシステム単位、組織単位で利用するか？環境（本番/ステージング/開発）ごとに分けるか？などを「管理」「課金」「組織」「運用」の観点から考え、AWSアカウントの分割点を検討します。
| 検討観点 | AWSアカウントを分割する理由 | メリット | デメリット |
|---|---|---|---|
| 管理 | セキュリティ及び管理上の理由から開発環境、テスト環境、本番環境でアカウントを分割したい |
|
|
| 課金 | 課金に関する可視性、責任、及びアカウントごとのコントロールを行いたい |
|
|
| 組織 | リソースの操作権限を特定のシステム（組織単位）に委譲し、その中でより自由にAWSプラットフォームを活用したい |
|
|
| 運用 | 構成変更時の影響範囲を小さくし、自身固有の環境を利用したい |
|
|
TISのAWSを利用したシステム開発への取り組み
以上のように、社内で複数システムが稼働する共通化基盤を検討する上では考えないといけない事は多々あり、また標準化された基盤は末永く利用される環境であるため、土台となる部分の構成変更は容易ではなく、慎重に準備していく必要があります。
TISでは、AWSの導入に向けた計画・検証から導入時の構築/移行作業、導入後の運用/ガバナンス、クラウド最適化までお客様の各フェーズに合わせたサービスを提供しています。お客様のビジネスの成功につながる、最適なクラウド活用をご提案いたしますので是非一度ご相談ください。
著：TIS株式会社 IT基盤技術事業部 IT基盤エンジニアリング第4部 エキスパート 山田 耕
