はじめに
この記事はDevOps on AWS大全 実践編の一部です。
DevOps on AWS大全 実践編の一覧はこちら。
この記事では開発環境のアーキテクチャを決める流れを解説しています。
具体的には以下流れで説明します。
- 解決したい課題の整理
- 今回使うAWSサービスの整理
- アーキテクチャの策定
- 策定したアーキテクチャで達成できたこと
AWSの区分でいう「「Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル」」の内容です。
この記事を読んでほしい人
- DevOpsエンジニアがアーキテクチャを決めるときにどのような思考フローを踏んでいるか知りたい人
- セキュアな開発環境のアーキテクチャを知りたい人
- AWS Certified DevOps Engineer Professionalを目指している人
解決したい課題の整理
現在、解決したいと思っている課題は以下になります。
- 各自のPC端末で開発することによる情報流出リスクを下げたい
- 開発環境はできるだけセキュアにしたい
どちらも、リモートワークをする上では解決することが必須の課題です。
ということで、これをどうやって解決するか考えていきましょう。
今回使うAWSサービスの整理
今回使う代表的なAWSサービスの概要とベストプラクティスを以下にまとめました。
Amazon WorkSpaces
Amazon WorkSpacesは、AWSクラウド上でデスクトップ環境を提供するサービスです。
ユーザーは、インターネットやVPN経由で、WindowsやLinuxのデスクトップにアクセスできます。
Amazon WorkSpacesは、セキュリティ、パフォーマンス、信頼性に優れたデスクトップ環境を、低コストで利用できます。
AWS Network Firewall
AWS Network Firewallは、AWSのVPCに対してファイアウォール機能を提供するサービスです。
AWS Network Firewallは、ネットワークレベルのトラフィックフィルタリングや検査を行い、不正なアクセスや攻撃を防ぎます。
AWS Network Firewallは、カスタマイズ可能なルールとポリシーを設定でき、自動的にスケールします。
AWS Client VPN
AWS Client VPNは、AWSのVPCやオンプレミスのネットワークに対してVPN接続を提供するサービスです。
AWS Client VPNは、OpenVPNプロトコルを使用し、セキュアな暗号化と認証を行います。
AWS Client VPNは、高可用性と弾力性を持ち、複数のリージョンやアベイラビリティーゾーンに対応します。
各サービスのベストプラクティス
| サービス | ベストプラクティス |
|---|---|
| Amazon WorkSpaces | - ユーザーごとに適切なバンドルタイプを選択する - ディレクトリサービスと連携する - ユーザーデータのバックアップを行う |
| AWS Network Firewall | - VPCごとにファイアウォールエンドポイントを作成する - ステートフルとステートレスのルールを組み合わせる - AWS Firewall Managerを使用してポリシーを管理する |
| AWS Client VPN | - クライアント証明書とActive Directoryを使用して認証する - セキュリティグループとネットワークACLを使用してアクセス制御する - CloudWatchとCloudTrailで監視とログ収集を行う |
アーキテクチャの策定
ここからはやりたいことを順番に考えながらアーキテクチャを策定していきます。
外部ネットワークから隔離されたセキュアなリモートデスクトップ環境が欲しい
まず、各自の端末で個別に開発している状況を解消してセキュリティリスクを下げる、という点を考えてみましょう。
これを実現するために最も簡単な方法はAmazon WorkSpacesを用いたリモートデスクトップ環境を準備することです。
Amazon WorkSpacesを利用すると、AWS内のプライベートサブネット内にリモートデスクトップ環境を簡単に準備できます。
バンドルの選択肢には日本語OSも含まれており、Windowsの場合にはOffice有無も選べます。
そのため、Officeは会社のライセンスを利用してコストを削減したいという要望を満たすことも可能です。
注意点として、Amazon WorkSpacesを利用するためにはユーザ管理のためのADが必要になります。
今回は、既存のADがない前提で新しくSimple ADを利用しましたがすでにオンプレやAWS上にユーザ管理しているADがある場合にはそれを流用することも可能です。
なお、今回の開発環境はコスト最優先で考えてSingleAZで組むこととしています。
マネジメントコンソールにつなぐからインターネットに出たい
Amazon WorkSpacesをプライベートサブネットに立てたことでセキュアなリモートデスクトップ環境は手に入りました。
しかし、AWSの開発をするならば、インターネットにつなぎたくなるのが自然な流れです。
ということでNAT GWをパブリックサブネットに追加して、インターネットへのルートを確保しています。
外部への情報流出を防ぐためにインターネットへのアクセスを制御したい
インターネットに出れるようになると出れない時と比べてセキュリティレベルは一段階落ちてしまいます。
NAT GWを利用しているので外部からの侵入リスクは軽減されていますが、内部からの情報流出経路ができてしまうからです。
そこで、インターネットに出る口のところでアクセス制御を行い情報流出リスクを下げたくなってきます。
ということでNetwork Firewallを追加して、アクセス制御を実現することにしました。
NetworkFireallはプロキシサーバと比べて、やや穴があるもののプロキシサーバを管理する運用コストを考えるとコスト増の影響が優位です。
そのため、NetworkFirewallを採用しています。
自分が使っている端末からリモートデスクトップ環境に対してセキュアに接続したい
ここまでで、インターネットへの情報流出リスクを下げたセキュアなリモートデスクトップ環境が完成しましたが、この環境に対してセキュアな接続を確立しないと誰も使えない環境になってしまいます。
要件によっていくつかの手段がありますが、今回はリモートワーク前提で考えたいのでAWS Client VPNを採用します。
不特定多数の端末がアクセスできないように証明書認証の実装を行いたいのでAWS Client VPNとセットでACMも利用する必要があります。
これで、各自の端末に証明書を配布すればVPNを介してAmazon WorkSpacesに接続することが可能となりました。
まとめ
本記事ではAWS内にセキュアなリモートデスクトップ環境を作って自端末からVPNでつなぎたいと思ったときにどういった思考フローでアーキテクチャを決めるかをまとめました。
今回策定したアーキテクチャで実現できたのは以下の項目です。
- プライベートなリモートデスクトップ環境
- インターネットへのアクセス制御
- リモートデスクトップ環境へのセキュアなVPN接続
次回はソースコードを管理するプライベートリポジトリの作成を考えてみたいと思います。