Amazon Web Services ブログ
AWS 移行に伴う組織体系の変化(前編)
１．はじめに
AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS へのシステム移行は、単純なシステム変更に留まらず、プロセスやチームの役割の変更を伴うため、これらに最適化した組織体制の構築が重要です。組織体制が旧来型のオンプレミス前提のままでもシステムをAWSに移行できますが、移行後の運用フェーズでAWSのメリットを最大限享受することはできません。本ブログでは、AWS への組織体系の変更における考慮点を具体的な例を交えて前編／後編に分けて提示します。前編では従来の組織における変化点についてご説明していきます。
２．オンプレミスと AWS の違い
従来のオンプレミスでは、ハードウェアの調達から設定、運用までを自力で行う必要がありました。これらを担うIT部門のインフラ担当は、見積や調達・設置・運用保守など、広範な知識と複雑なプロセスが必要でした。AWS を利用する場合、数クリック、数分間でリソースを増減できるため、オンプレミスのような購買調達プロセスが簡略化されます。ハードウェアは AWS のサービスをインターネット経由で利用するため、自前での調達・設置、数年先を見据えた計画立案などが不要になります。さらに、マネージドサービスやサーバーレスなどのサービスを活用することで OS、ミドルウェアの設定・運用保守の運用負荷も軽減できます。
セキュリティについても、従来のオンプレミス環境とは異なる視点が必要です。AWS では、AWS 側とお客様側で責任範囲が分かれる「責任共有モデル」を理解する必要があります。AWS がクラウド環境自体の責任を、お客様にはクラウド内のセキュリティに対する責任と管理を担っていただきます。この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。
３．IT 部門の変化
３－１．アプリケーション部門・インフラ部門の変化
IT 部門では、アプリケーション担当とインフラ担当の役割が明確に分かれているのが一般的です。システム開発においてはアプリケーション担当とインフラ担当の調整が発生し、開発スピードを低下させる要因となっていました。例えば、アプリケーション部門が新たな開発環境を調達する際、インフラ部門による構築・検証の完了を待つ必要があり、依頼からリードタイムが発生します。一方、AWS ではサーバーレス、マネージドサービス、IaC ( Infrastructure as Code )による環境の複製など、操作が容易で開発スピードを向上させるサービスが提供されています。アプリケーション部門がこれらの AWS サービスを有効活用することにより、インフラ部門の対応を待つことなく自力で環境を作ることができ、開発スピードの加速が可能となります。つまり、AWS の活用によって、従来の IT 部門組織における開発スピードの課題を解決することができるのです。アプリケーション部門が AWS サービスを活用することで、開発プロセスの効率化と迅速化が期待できます。
３－２．運用部門の変化
開発スピードを向上するためには、開発と運用が一体となった DevOps 組織の編成が効果的です。DevOps は、従来の開発部門と運用部門の垣根を取り払い、両者が協力して素早くアプリケーションの改善を行うアプローチであり、クラウドの特性と適合しています。両者が分かれている場合、開発部門は目標としてリリース頻度や変更容易性を重視しますが、運用部門はシステムの安定性と効率化を重視する傾向があるため、部門間の対立・調整が課題となっていました。DevOps では開発と運用に取り組むメンバーが、同一の組織としてアプリケーションのライフサイクル全体を推進することで、目標が対立することなく開発を進めることができます。DevOps では自動化が重要な役割を果たします。アプリケーションのビルド、テスト、デプロイなどの工程を自動化することで、ヒューマンエラーを排除し、高速かつ安定したリリースサイクルを実現できます。
３－３．組織の運用モデル
AWSのWell-Architected Frameworkの運用の優秀性の柱では、運用モデル 2 x 2 が表現されており、チーム間の関係を理解するのに役立ちます。また、モデルごとのガバナンスや意思決定プロセスについても提示しています。現在各チームがモデルの中でどの位置にいるか、チームの関係と責任がどのように変わるか、変更が組織への影響に見合っているかどうかを確認します。いずれのモデルにもメリット・デメリットがあるため、組織として達成したいビジネスゴールを設計・共有したうえで、優先度を判断し、選択することが重要です。
４．セキュリティ部門の変化
オンプレミスの環境におけるセキュリティ部門の主な業務は、システムやネットワークの監視・管理、ファイアウォールやエンドポイントセキュリティなどのソフトウェア設定と運用、物理的なアクセスの管理などです。さらに、社内の基盤システムに関わるセキュリティ対策として、データバックアップ、侵入検知や脆弱性管理、ID・アクセス管理なども行います。つまり、オンプレミスの環境ではシステム基盤自体のセキュリティ管理が重要な役割となります。
一方、AWS では、AWS が大部分のセキュリティ機能を提供するため、セキュリティ部門の役割が大きく変わってきます。AWS 環境では「責任共有モデル」が適用され、AWS 側とお客様側で適切にセキュリティの責任を共有する必要があります。具体的には、AWS がネットワーク、ストレージ、データセンターなどのインフラストラクチャのセキュリティを担当し、お客様側が AWS 上のデータやアプリケーション、ID・アクセス管理などを担当することになります。
このため、AWS 環境でのセキュリティ部門の役割は、AWS 上のデータやアプリケーションの保護、ID 管理やアクセス管理、脆弱性管理やモニタリングなど、AWS 上のリソース管理が中心となります。具体的な AWS のセキュリティサービスには、AWS Shield、AWS WAF、Amazon GuardDuty などがあり、DDoS 攻撃の防御や Web アプリケーションファイアウォール、高度な脅威検知などを提供しています。また、AWS Control Tower のガードレール機能を活用すれば、ベストプラクティスに沿った自動的なリソース設定の維持管理も可能です。
このような 変化に対応するため、セキュリティポリシーの見直しが必要になる場合があります。 オンプレミスのセキュリティポリシーは、社内ネットワークや物理的リソースへのアクセス管理を前提としていますが、AWS ではインターネット経由でのアクセスが前提となり、外部からの脅威にも対応できるようなポリシーへの変更が求められます。例えば、アクセス制御においては、多要素認証（MFA）の導入や最小限のアクセス権限の付与といった、AWS のベストプラクティスを考慮することが重要です。
この責任共有モデルを組織に適切に組み込むためには、まず AWS セキュリティチームを設置し、AWS とお客様側の責任分界線を明確にする必要があります。そして、セキュリティポリシーの見直しや利用部門や開発部門への教育、定期的な監査とコンプライアンスの確認に取り組みます。
このように、オンプレミスと AWS では、セキュリティ部門の役割やセキュリティポリシーが大きく異なります。特に AWS 環境では、AWS のセキュリティ機能を最大限活用しつつ、お客様側の責任範囲におけるセキュリティ管理を適切に行うことが重要となります。
まとめ
前編では、従来のオンプレミスとAWS の違いから、IT 部門、セキュリティ部門の変化について整理しました。後編では、AWS によって新たに組成する組織や、組織文化の変更についてご紹介していきます。
カスタマーソリューションマネージメント統括本部
カスタマーソリューションマネージャー (CSM) 甲斐 裕之、山崎 徹