Sekappyではエンジニア向けの開発環境としてAWSの各種サービスを利用しています。EC2、RDS、S3、Cloudfrontなどが主なものです。

高度情報化社会においてセキュリティは切り離すことのできない、必ず考慮すべき要素の一つであると言えます。たとえ開発環境だとしても、情報資産へ不特定多数のアクセスが発生することは好ましくありません。

そこで今回は、セキュリティを担保するAWSのサービスについて紹介と解説をしていきます。

AWSのリソースを守る手段

現在、社内開発環境で利用している主なセキュリティ関連サービスを以下に図示します。

やたらと主張の激しいサービスが右にいますが、それだけ重要かつ強力なセキュリティサービスです。

一つずつ解説していきます。

Identity and Access Management(IAM)

IAMはAWSでシステムを構築する上でなくてはならない存在です。そもそもAWSのWebコンソールを操作するための権限付与はアカウント作成直後にrootユーザがIAMからAdmin権限を持つスーパーユーザを作成するところから始まります。

IAMはAWS上のサービスやリソースへのアクセス権限をすべて管理しているサービスで、Webコンソールの操作や各種リソースの閲覧、作成、変更、削除など様々な要素を制御することが可能です。この後に説明されるすべてのセキュリティ関連サービスもこのIAMが許可しない限り設定はおろか作成することすらできません。また、それらのセキュリティ関連サービスで制限されている操作であっても、設定方法によってはIAMの権限が勝ってしまう場合もあります。基本的にAWSで作成されるシステムはインターネットへの公開が前提となっていると思われますが、IAMの権限さえあればバックドアからアクセスすることも可能です。

もちろん、強力な権限を有していますので、設定や共有には細心の注意を払う必要があります。

Virtual Private Cloud(VPC)

VPCはAWSの中でネットワーク空間の役割を果たします。基本的にAWSの中でネットワークを伴うすべてのサービスはVPCの中に構築されることになります。

VPCはサブネットやゲートウェイなど、実際のネットワークでも利用される仕組みがクラウド上で構築されており、オンプレミス環境との通信や他のAWSアカウントとの接続なども可能となっています。実際のネットワークと同じ仕組みで動いているため、通信の許可に関しても現実のファイアウォールに相当する機能であるACL(Access Control List)を使って制御が可能です。ACLではネットワーク上のIPと通信ポート番号をベースにした制御しかできませんが、通信がVPC内のリソースへ到達する前に完全に遮断することが可能(しかもほぼ無料)なので、DDoSなどの不正アクセスに対して一番コストパフォーマンスが高い対策となり得ます。

Web Application Firewall(WAF)

WAFはVPCのACLと一部役割が被っていますが、ACLがIPベースであるのに対してWAFはIP、アクセスヘッダー、アクセス頻度、アクセス先URLなど様々な要素を基にした制御が可能なサービスです。

弊社開発環境ではCDNであるCloudfrontのアクセス制御に利用していることが多いです。できることが多いのですが、当然色々なことをやろうとすると使った分だけ従量課金が発生しますし、アクセスのログを保存する場合はそちらも別途費用が発生します。それでも、制御方法の多さと適用の容易さは他のサービスより頭一つ出ていると思います。

Security Group

普段EC2やRDSを利用している方であればよく目にしているであろうセキュリティグループですが、VPCのACLと同様にIPと通信ポート番号をベースにアクセス制御を行います。

個別のリソースへのアクセスを制御するためにはVPCのACLで許可した通信を更にふるいにかける必要があり、そのふるいの役割を果たすのがセキュリティグループです。セキュリティグループはEC2インスタンスの他ロードバランサやRDS、Elasticache、DynamoDBなどWebサービスで頻繁に利用されるサービスではほぼ必須のセキュリティ機能となっています。

Cognito

前述の4つは許可するか、拒否するかの2択を突きつけるセキュリティ対策でした。Cognitoはアクセス者に認証という第3の選択肢を与えます。

CloudfrontやロードバランサでIP制御ではなく認証情報を持つユーザにのみページの公開を行いたい場合に利用できます。ユーザプールと呼ばれるリストでAWS内で認証情報を管理する以外に、外部の認証情報(RADIUSやMS ActiveDirectory、各種SSO)を使った認証管理も可能です。本投稿も含め弊社が公開している技術ブログは社内メンバーのみが閲覧可能な技術共有ブログの中から公開用に加筆・修正を加えたものでして、社内向け技術共有ブログへのアクセス制御をCognitoとGoogle Workspaceのアカウント連携で実現しています。

Cognitoは後段に控えるリソースと完全に切り離されて管理されており、DDoSなどの各種不正アクセスに対しても高い防御力を発揮します。その昔webページの認証といえばBasic認証が広く用いられていましたが、実装と管理の手間や攻撃のリスクを考慮すると、現代では「ないよりマシ」レベルのセキュリティ対策でしかありません。対してCognitoは、とても手軽にAWSの堅牢な基盤を利用した認証システムを組み込める画期的なサービスであると言えます。

まとめ

AWSで利用されるセキュリティ対策サービスや機能について解説しました。
実際にこれらの対策を施す場合は、システムの要件やアクセス頻度、管理のしやすさなどを考慮して複合的に各サービスを設定することが多いです。また、対象のリソースでどのセキュリティ対策機能が使えるのかも把握しておく必要があります。

システムへのアクセスを制御する必要があるかどうか、あるのであればどのように制御するのか、今自分が触っているシステムはセキュリティ的に適切に制御されているのか、というようなことを頭の片隅に置いておくと、例えば『社内からは正常に表示されるwebページがお客様環境だと正しく表示されない』といった問い合わせがあった場合に「そもそもお客様環境からのアクセスは許可されているのだろうか」と疑問を持てるようになったりするのではないかと思います。

普段インフラに関わらないエンジニアの皆様にセキュリティやアクセス制御に関心を持っていただくことで、本投稿がセキュリティリテラシーの向上とセキュリティインシデントの防止に役立てば幸いです。