AWS

AWSで構築する閉域網のシステムにおける落とし穴!よくある設定漏れと対応について解説

aka

はじめに

本記事では業務システムにおいて採用されることも多いAWSによる閉域網システム構築において、よくある設定漏れについて簡単に解説します。業務で扱うことも多く、セキュリティを強化できる一方、設定ミスによる問題も多い閉域網システム。業務の中で得た知見を盛り込んでいますので、同じ課題に取り組むエンジニアの方々の一助になれば幸いです。

VPCエンドポイント・ゲートウェイエンドポイント

閉域網環境においては、VPCのサブネットに配置した各リソースから、必要なAWSサービスへのアクセスを行うためのVPCエンドポイントやゲートウェイエンドポイントが必要不可欠です。
よくあるのは必要なエンドポイントの見落としや設定漏れです。
特に、S3、DynamoDB、ECR、CloudWatchなどの主要サービスのエンドポイントは要注意です。
エンドポイントの設定不足は、サービス間通信やデータ転送の失敗につながりますが、実行時のエラーとしてはTimeOutとしか出力されないことが多く、トラブルシューティングが困難な原因の一つです。
適切なエンドポイント設定を確認し、必要に応じて追加することが重要になります。

意外と見落としがちなCloudWatch

上記エンドポイント不足の話に関連するのですが、閉域網環境においてSageMaker Stdioのアプリケーションなどを使用して開発を行う場合、開発環境上には実行ログが出力されないことがあります。その場合はCloudWatchのVPCエンドポイントの設定不足が原因となっているかもしれません。コンピューティングリソース上からAWSのパッケージをインポートして使用する際には内部的にCloudWatchが呼ばれていることもあり、その結果意識的にCloudWatchを使用しておらず、別のサービスのパッケージを使用していたとしてもCloudWatch Logs用のVPCエンドポイントが正しく設定されているか確認が必要となります。
そこに付随してIAMロールにCloudWatchログへの書き込み権限が付与されているかも重要なチェックポイントとなります。

ENI経由で実行されている場合

Elastic Network Interface (ENI) 経由で実行されるリソースは、特有の設定が必要となります。
SageMakerやGlueといったコンピューティングリソースを閉域網で実行する場合はプライベートサブネット上に配置されたENIを経由して各リソースへアクセスすることになるため、ENIに関連付けられたルートテーブル、セキュリティグループ、サブネットの設定を確認し、各リソースへの通信経路が成立しているか確認することが重要です。
また、ENIのプライベートIPアドレスが適切に割り当てられ、DNSが正しく解決されているか確認することも重要です。
ENI関連の問題は複雑になりがちですが、実行されるリソースがどこから実行され、どこに配置されたリソースにアクセスするのかをきちんと理解し、経路中の要素を上記のようにピックアップすることで、システマティックな確認で解決が可能です。

セキュリティグループのインバウンド設定

閉域網環境に限った話ではないですが、通常のシステムと同じく、セキュリティグループにおいてもインバウンドルールの設定ミスにより通信が行えないケースがあります。(原因は違えど上述のネットワーク関連の不具合と同じように、実行リソース上ではTimeOutエラーしてしまうため原因として察知しにくいです。)
必要なポートやプロトコルの開放漏れ、過度に制限的な設定などが主な問題となります。
適切なセキュリティグループ設定は、サービス間の通信を確保しつつ、不要なアクセスを遮断することにも繋がるため、定期的な見直しと、AWSのベストプラクティスである最小権限の原則に基づく設定を推奨します。

必要な許可ポリシーの不足

ポリシーに関しても閉域網環境に限った話ではないですが、通常のシステムと同じく、AWSリソースの実行には、適切な権限を持つIAMロールが必要です。
連携するリソースに対しての権限もそうですが、忘れがちなCodeArtifactへのアクセスやS3バケットへの読み書き、CloudWatchの読み書きの権限などに注意が必要。

バケットポリシー

S3バケットのアクセス制御は、バケットポリシーで細かく設定可能ですが、閉域網環境においては、過度に制限的なポリシーや、必要な許可の漏れによるアクセスの失敗も多々発生します。
上述までの項目が満たされていたとしてもバケットポリシーの設定ミスで同じくデータアクセスの失敗に繋がるため、注意が必要です。

リソースが停止している

こちらも閉域網環境に限った話ではないですが、上述したような部分に目が行きちになると基本的な部分であるリソースの稼働状態の確認を忘れがちです。
EC2インスタンス、RDSインスタンス、ECSタスクなどの稼働状態を確認することが重要です。
停止中のリソースは、ネットワーク接続やサービス提供ができないため、問題の原因となります。
自動スケーリングやスケジュールされた停止などの設定も確認する必要があります。

pipインストール時にインターネットアクセスしようとして失敗

閉域網環境でのPythonパッケージインストール(pip等)についても、オプションなしで実行した場合、バックグラウンドではインターネットアクセスを行い必要なパッケージをダウンロードしてこようとするため失敗しがちです。
この問題の解決には、CodeArtifactからのダウンロードやプライベートPyPIリポジトリの構築やS3バケットの利用が効果的です。
また、Dockerイメージ内に必要なパッケージを事前にインストールする戦略も考えられます。
閉域網に適したパッケージ管理戦略の採用が、開発効率の向上に繋がります。

最後に

AWS閉域網環境の設定は複雑ですが、適切な理解と対策で多くの問題を回避できます。
本記事で紹介した項目を参考に、構築環境を見直すことをおすすめいたします。
定期的な設定の見直しと、最新のAWSベストプラクティスの適用も重要です。
セキュリティと利便性のバランスを取りつつ、効率的な閉域網環境を構築しましょう!

AUTHOR
aka
aka
記事URLをコピーしました