はじめに
皆さん、業務でAWSは使われているでしょうか。
昨今、様々なサービスや機能がAWSを基盤として構築されていますよね。
今回は皆さんに、AWS上に構築されたサービスにいきなりアクセスできなかったときに、何を確認すべきかということをざっくりと伝えていければと思います。
例えば、URLをブラウザから入力すると画面が立ち上がり様々な情報を参照できるWEBサービスなどを公開していると仮定してください。
あなたはSREとして配属されてきたばかりの初心者AWSerです。
ある朝、早起きして会社に来るとSlackで以下のような連絡を受けました。
コンサル「いまお客様先でデモンストレーションをしようとWEBサービスにアクセスしたところ、403エラーになって接続できません！社内ネットワークからは接続できますし、社内ネットワーク内の別のサービスにもアクセスできます...先週はアクセス出来たのに...急いで解決してください！URLとAWSアカウントはこれです！」
URL
- https://example.edu
AWSアカウント
- 123456789012
事象
- URLにアクセスしたら403エラーが表示される
前提
AWSアカウントの所持は当然として、windows10にwslをインストールした状態を想定しています。
digというコマンドを使います。
調査の流れ
エラーの内容から推測
403 Forbiddenエラーは、ユーザーがURLにアクセスしたときにHTTPサーバーからユーザーに送信されるHTTPステータスコードです。
この結果から、ある程度何が問題なのか絞り込むことができます。
ここで帰ってくるエラー内容によってアクションも変わってきますので、必ず確認してください。
403は指定したページへの閲覧禁止を意味します。
このことから、ページにアクセスるまでの経路のどこかで、「社外ネットワークからページへのアクセスを拒否する」ようになっていることが予測できます。
リージョンとelbを確認
アカウントはわかりましたが、対象の環境のインスタンスがどこにあるか、そもそもどこからアクセスを受け付けているのかもわかりません。
そこで、URLからドメインを取り出して、そこからdigを叩いてみましょう。
※こちらはテスト用のドメインのため、実際の結果は異なります。
dig example.edu
;; ANSWER SECTION:
example.edu. 3600 IN CNAME example.edu-123456789.ap-northeast-1.elb.amazonaws.com.
example.edu-123456789.ap-northeast-1.elb.amazonaws.com. 60 IN A 1.111.11.111
example.edu-123456789.ap-northeast-1.elb.amazonaws.com. 60 IN A 11.111.111.111
digはドメインからサーバーやらIPやらといった内部情報を引き出すことができるコマンドです。
AWSアカウントは123456789012と教えてもらえたので、上記の情報からap-northeast-1リージョンにあるロードバランサーexample.edu-123456789がアクセスを受け付けていることがわかりました。
ロードバランサーのリスナー確認
リスナーは設定されたプロトコルおよびポートを使用して接続リクエストを確認し、ロードバランサーはリスナールールを使用してリクエストをターゲットにルーティングします。
以下のように管理コンソールから画面遷移しましょう。
AWS管理コンソール>ap-northeast-1リージョン>EC2>ロードバランシンググ>ロードバランサー
ここで先ほどdigで検索したexample.edu-123456789.ap-northeast-1.elb.amazonaws.comというDNS名のリソースを探し、リスナータブを確認してみましょう。
ここでは画像のように、HTTPSによる接続を受け付けていることがわかります。
このことから、アクセスにコンサルが使用していた「ttps://example.edu」のプロトコル部分も、ドメイン名の部分も問題ないことがわかりました。
また、TLSセキュリティポリシーがELBSecurityPolicy-TLS-1-2-2017-01なので、いくつかのプロトコルは下記の通り受け付けていないことがわかります。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/elb-security-policy-table.html
もしもコンサルが使用しているブラウザがProtocol-TLSv1やProtocol-TLSv1.1をつかってアクセスしようとしていたなら、接続ができなくなる危険性はありそうですね。
その場合はコンサルのブラウザの設定を確認してもらえばよいでしょう。
今回はこれではなかったとします。
ロードバランサーのセキュリティグループを確認
セキュリティグループは、対象リソースに対してアクセスできる権限を、IPやセキュリティグループを持っているリソースという単位で絞り込むことができます。
今度はロードバランサーにアタッチされているセキュリティグループを確認してみましょう。
説明タグからセキュリティグループを確認します。
インバウンドは通信を受け付ける設定、アウトバウンドは無効から見てアクセスできる場所の設定です。
HTTPSでは0.0.0.0/0、つまりすべてのIPアドレスへの接続が許可されていることがわかりました。
セキュリティグループの設定でも、ドメインでも、接続プロトコルでも問題が無さそうです。
なお、セキュリティグループはEC2インスタンスにも紐づけられるので、インスタンスのセキュリティグループも確認すると良いでしょう。
このとき、elbを使用している場合はだいたいセキュリティグループのIDが登録されているケースが多いです。
これは、そのセキュリティグループがアタッチされているリソースからのアクセスを受け付けるという意味になります。
ロードバランサーのWAFを確認
WAFはこれまたアプリケーションへのアクセスを制御できる機構です。
もう一度ロードバランサーに戻って、今度は統合サービスタグを確認してみましょう。
どうやらAWS WAFが有効になっているようです。
WAFでも接続可能なIPアドレスなどを絞り込むことができるので、確認してみましょう。
WAFはクラシックかそうでないかでリソース事分かれているので両方確認してください。
今回はクラシックでしたのでハイライトしているボタンで画面を切り替えます。
以下のように画面を移動してください。
Web ACLs>使用しているACLを選択＞Rulesタグ＞使用しているルールを選択
どうやらここでアクセス可能なIPアドレスを個別に管理しているようでした。
コンサルが使用しているパブリックIPアドレスがここで登録されていなければ、接続ができなくなる危険性はありそうですね。
私が実際にこの問題を対応したときはここが原因でした。
これ以外にも見れる場所はあるので、そちらも紹介しておきます。
ロードバランサーの存在するVPCを確認
VPCは、リソースが存在している大きなネットワークの箱です。
こちらにも、VPC単位で接続を制御できるようになっており、ここで無効になっていればVPC内のすべてのリソースにアクセスできなくなります。
VPCのアクセスコントロールリストを確認してみましょう。
こちらはVPCのデフォルトの設定です。
こちらもインバウンドが受け付ける通信で、アウトバウンドが外に出ていく通信です。
ルールというのはただの識別番号で、はすべてのルールに当てはまらない場合に適用される内容です。
デフォルトではルール100によってすべてのIPからの接続を受け付けているため、が適用されるタイミングが無く、すべての接続を受け付ける状態となっています。
ここでIPの制御をしていた場合は、アクセスできなくなる危険性があります。
おわりに
ここまでざっくりと汎用的に使われるアクセス制御部分の確認手順をさらってきました。
今回は私が実際に対応したケースに従って紹介してきましたが、本当にそのタイミングでは頼れる人がおらず、知識もなく、自分で探してまとめて行くのが大変でした。
AWSはいろんな段階でそれぞれアクセス制御をかけることができるので、それぞれのリソースが複雑に絡み合い把握がとても大変です。
自分で運用する場合は、その環境に適した確認手順を作っておくと良いでしょう。
私もAWS初心者（クラウドプラクティショナー程度）であるため、ご指摘・ご質問・ご感想はどのようなものでもありがたくいただく所存です。
特に「ここも確認したほうが良い」といった内容はぜひお伺いしたく存じます。
何かございましたら、ぜひコメントを頂ければと存じます。
以上、お疲れ様でした。