初めに
これは ドリコム Advent Calendar 2021 の20日目です。19日目は なかはらつ さんの 無邪気にSelenium4にアップデートしたら既存コードがぶっ壊れたので対応した話 です。
自己紹介
こんにちは、今年ドリコムに新卒で入社したサーバサイドエンジニアの宮島です。 今回はAWSでEC2やCloudFrontを使ったWEBアプリケーションを構築する場合に、おそらく意識するであろうアクセス周りのセキュリティ設定についてお話しします。私自身、AWS歴半年の超絶初心者なので詳しいわけではないですが、これ便利だな〜なんて思ったことを紹介させて頂こうと思います。
今回お話しするのはこの3つについてです。
- EC2のセキュリティ設定
- WAFの設定
- S3のセキュリティ設定
EC2のセキュリティ設定
EC2とはElastic Compute Cloudの略称で、インスタンスと呼ばれる仮想的なコンピュータをクラウド上で提供しています。インスタンスの操作はssh接続やリモートデスクトップ接続で行うことができ、また、EC2の機能であるロードバランサを通して特定のネットワークからインスタンスへのHTTPアクセスを制御したりもできます。
インスタンスやセキュリティグループを作成するためにはVPC(Virtual Private Cloud)が必要です。VPCは仮想的なネットワークです。このネットワーク上にEC2などのAWSサービスを構築し、セキュリティグループによってアクセスを制限します。 セキュリティグループでは、あらかじめどのポートでどのような通信をするのかを決めることができます。
AWS が用意した default という名前がついたセキュリティグループでは全てのポートから全てのプロトコルを許可するので、インターネットに接続させたくないインスタンスなどがあれば新しくセキュリティグループを追加する必要があります。
例えば、インバウンドルールでは外部からEC2やロードバランサにアクセスできる条件を追加できます。
この例ではローカルホストからなら8000番ポートにTCP接続できたり、443ポートにHTTPS接続可能だということがわかります。
実際の現場では、ステージング環境用にVPNや社内で使用している特定のIPアドレスからのアクセスを許可するような設定だったり、本番環境用に外部からアクセス可能な設定を作成していると思います。
ステージング環境の作成でも、ロードバランサにWAFの設定を施すまでは外部からアクセスできないようにするなどの工夫をしてみましょう。
外部からのアクセスを許してしまうと情報漏洩につながります。
扱いに気をつけないと大変なことになる可能性があるポイントの1つです!
WAFの設定
次にお話しするのは WAF(Web Application Firewall)についてです。ファイアウォールという言葉は聞いたことがある人が多いのではないでしょうか。
こちらもリソースに対するアクセスを制限するものですが、アプリケーションロードバランサやコンテンツ配信サービスであるCloudFrontに設定することができます。
セキュリティグループと違うのはアクセスの許可だけでなくブロックする条件を設定できることやIPアドレス以外の条件でも規制できるという点です。
Web ACL(Access Control List)ではそれらのルールを実際に決めることができます。
まずはAWS WAFからWeb ACLを作成してみましょう。 ac21という適当な名前のWeb ACLを作成してみます。
このACLは先ほどのロードバランサなどを対象にWAFを適応することができます。
ロードバランサにはセキュリティグループがあるのになんでWAFも必要なの?と思った方もおられることでしょう。
例えばHTTPリクエストに何かヘッダがあるとします。
下記画像の設定の場合、ramenヘッダが”iekei”でなければそのアクセスをブロックすることになります。 これらの条件とロードバランサを組み合わせることで、特定のヘッダをつけてHTTPリクエストを飛ばした時にWAFでヘッダの条件を確認しつつ、セキュリティグループでアクセス元のネットワークアドレスが正しいか確認することで、2つの観点からリクエストを捌くことができます。
この条件はif文のようにTRUE, NOT, AND, ORの4パターンがあり、それに対するアクションもAllow, Block, Countの3種類があります。
またHTTPリクエストのヘッダ以外にもクエリパラメータやリクエストメソッドなどがあるので是非試してみてください。
S3のセキュリティ設定
最後はS3についてです。S3とはAmazon Simple Secure Storageの略称で、簡単にいうとストレージサービスです。 使用例としてはアプリケーションログを貯める、サービスのバックアップを取る、ビッグデータ解析など幅広く使うことができます。
実はS3だけでウェブサイトを構成することが可能で、index.htmlなどを含むサイトアセットの置き場所としても活躍してくれます。 このようなファイルの置き場所の単位をバケットと言います。
独自のドメインを使用してウェブサイトを公開する場合はCloudFrontからS3のリソースにアクセスすることができ、その場合CloudFrontからS3のバケットをオリジンドメインとして指定します。 S3のオブジェクトにはそれぞれオブジェクトURLというものがあり、パブリックアクセスがオンの場合はS3のオブジェクトに直接アクセスすることが可能です。
しかし、そのような場面はあまり多くなく、基本的にS3へのパブリックアクセスはオフにしていることが多いと思います。
では、パブリックアクセスはできないのにどのようにしてS3のデータを見ることができるのでしょうか?
これはバケットポリシーで制御することが可能です。
バケットポリシーとは、S3バケットに対するアクセス許可の設定で、他のAWSのサービスや特定のIPアドレスなどからのアクセスを制限できます。
例えば以下のようなjson形式のものです。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity (KEY)" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::(バケット名/公開するファイルのパス)" } ] }これは OAI(Origin Access Identity) というIDを持つ CloudFront からバケット内のオブジェクトを参照することができます。
この場合、S3のオブジェクトへのパブリックアクセスはできない状態で、CloudFrontからはアクセス可能なのでウェブサービス上ではS3のデータを扱えるような振る舞いになります。
また、上記の例ではバケットについてのアクセス許可について例を挙げましたが、個々のオブジェクトに対するアクセス許可も設定することが可能です。つまり、フォルダのルートに対する権限と、末端のファイルに対する権限を分けることができる感じです。
まとめ
このように、AWSのサービスにはファイルやサービスに対してアクセス周りの設定がボタン操作で簡単にでき、セキュリティを意識して誰でも扱うことができます。情報漏洩などをしない安全なサービスを構成できるようにこれからも努めていきましょう。
今回のまとめ
- EC2のセキュリティ設定
- EC2のインスタンスやロードバランサは、ネットワーク設定によっては外部からアクセス可能になってしまう
- EC2のインスタンスやロードバランサは、セキュリティグループによってIPアドレスでアクセスを制限することができる
- WAFの設定
- WAFはIPアドレス以外でもアクセスの許可とブロックができる
- S3のセキュリティ設定
- S3のリソースへのアクセスはバケットやオブジェクト単位で管理できる
- バケットポリシーを設定することで、他のAWSサービスからアクセスすることができる
- 個々のオブジェクトに対してパブリックアクセス可能かどうか設定できる
おわりに
21日目は渡辺 祥二郎さんの記事です。ドリコムでは一緒に働くメンバーを募集しています!
募集一覧はコチラを御覧ください!