saijaku_plus
@saijaku_plus

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

AWSの本番サーバーをプライベートサブネット上に置く意味が分かりません。

Q&A

セキュリティ上パブリックサブネットには本番サーバーを置くべきではないですか?

このような構成がセキュリティ上問題がある場合がありますか?

image-22.png

AWS初心者であり、独学でITのことを勉強しているため未経験で業界のことを全く知りません。
最近ネット上の構成図を見ていると上記のようにパブリックサブネット上にサーバーがあるタイプではなく、下記のようにEC2インスタンスやALBをパブリックサブネットに踏み台のようにおいてからプライベートサブネットに本番サーバーを置いているのを見かけます。
20210513232306.png

セキュリティ上パブリックサブネットには本番サーバーを置くべきではないですか?
言葉足らずかと思いますが、よろしくお願いします。
質問の意味が分からない場合でもコメント残してくださると助かります。

1

6Answer

外部からの攻撃については皆さんがご説明された通りですが、サーバーをプライベートサブネットに置くことは内部からの攻撃に対する防御にもなる点について、蛇足ですが補足させていただきます。

昨今のプログラム事情であれば、OSに組み込まれているものなどもも含めて多くのライブラリ群をサーバーにインストールして動かすことになると思います。
そのライブラリのわずか1つに悪意あるプログラムが含まれると、例えば内部ログなどの機密情報を盗み見られてしまうかもしれません。
その場合において、プライベートサブネットに置かれたサーバーでは、外部「から」の通信を遮断するだけでなく外部「へ」の通信も遮断しますので、盗み見られた機密情報を攻撃者のもとへ送信することができません。

外部「へ」の通信の遮断は、サーバーごとのセキュリティグループでも設定が可能ですが、逆に設定をし忘れたり、設定を更新し忘れたりすると脅威にさらされることになります。
ですので、あらかじめ外部と通信しないことが分かっている場合には、プライベートサブネットにいれてしまうことで「間違っても外部と通信できない」ようにしておく、というのは一つのベストプラクティスになっているというわけです。

このベストプラクティスは外部への通信を行わない場合にのみ使えるもので、サーバーの処理内容次第では外部へ通信する必要があり(外部サービスのAPIを呼び出すなど)ますが、その場合はプライベートサブネットに置いてしまうと通信ができなくなってしまうので、このベストプラクティスで内部からの攻撃にたいするセキュリティメリットを享受することはできません。

「間違っても外部"から"の通信を受け付けたくない」が、「外部"へ"の通信は許可したい」という場合には、プライベートサブネットにサーバーを配置した上で NAT Gateway を併設するという手法がとられます
この場合、外部からの攻撃に対するセキュリティメリットは享受できますが、内部からの攻撃に対するセキュリティメリットは享受できないことに注意してください

さらに補足しておくと、外部"へ"の通信がAWSサービスのみが対象の場合、VPC Endpoint を利用することにより、プライベートサブネットに置いたままAWSサービスのみに対して通信を許可することができます
この通信経路はインターネットを経由しないため、たとえ設定を間違えたとしても第三者へ通信が行われることはなく、内部からの攻撃に対してもセキュリティメリットを得ることができます

3Like

FW,LBの堅牢さにより、パブリックに配置している方もいます。

しかしながら、プロキシ、LBをパブリックに配置し、アプリケーションサーバはプライベートに配置すると安心感があります。

パブリックは外界からIPが晒されており、
プライベートはルーティングされない安全な場所です。

      障壁 障壁  障壁
      |   |   |
FW--proxy(LB)----コンテナ-----LB--DB
          | 
        アプリサーバ

のような構成もあり、情報漏洩を絶対にさせないポリシーの現れです。

【FW,LBの堅牢さ】ってなんでしょうか?
侵入されないこと?私は侵入されても、万が一サーバが乗っ取られても?、データが外にでないように障壁を配置することと考えます。

まあ、下世話な言い方ですが、個人なら、尻の穴の小さい人間が安心感を得るためですが、企業ならの生存競争のための経営判断と思います。

1Like

Comments

  1. @saijaku_plus

    Questioner

    質問の仕方が言葉足らずでした。
    箇条書きになってしまいます。申し訳ないです。
    ・僕自身はパブリックにアプリケーションサーバを置いてもいいと考えていた。
    ・しかし、ネットの構成図を見てみるとプライベートサブネットにアプリケーションサーバを置いている人が多い。

    アプリケーションサーバをプライベートサブネットにするべき理由、パブリックサブネットにしてはいけないセキュリティ上考えられる懸念点。を知りたいです。よろしくお願いします。

「~にするべき」というほど強い理由なら探せば説明してる人がいるでしょう。
「~してる人が多い」程度でそこまで積極的な理由があると考えるのは無理があります。
(設定ミスのようなヒューマンエラーの保険にはなるかもね)

あと、「パブリックにアプリケーションサーバを置いてもいいと考えていた」の立場からその理由を説明してみると気づけることがあるかもしれません。
「プライベートにする理由を知りたいがパブリックにする理由は必要ない」では非対称ですからね。

1Like

Comments

  1. @saijaku_plus

    Questioner

    ご回答ありがとうございます。
    自分自身日本語が下手なので回答になっているのかわかりませんでした。
    申し訳ないです。。。

ロードバランサがあってそれを通すルートしか許さない設定にしているのにインターネットからアプリサーバが直接アクセス出来たらロードバランサの意味無い。ロードバランサはhttpsだけ公開だからリスク少ないけどアプリサーバはDB通信必須だからDBもセキュアなもの使う必要が出てくる。

1Like

大前提として、パブリックサブネットにアプリケーションサーバーを置くことが禁止されているわけではありません。

ただし、セキュリティを考えるとパブリックに公開するサーバーは最小限にすべきです。(インターネットに公開するものは最小限にしましょう、という考え方です)

サービスを提供するうえで、「最低限これはインターネットに公開(パブリックサブネットに配置)しないといけない」ものは何か考えてみると良いと思います。

答えを言ってしまうと、ALBが公開されていれば(EC2が公開されていなくとも)サービスが提供できます。
よって、EC2はプライベートサブネットに置く、ということになります。

1Like

通行人が、飲食店に出入りし、危害を加える(悪戯をするなど)例で例えてみます。

パブリック…屋外の屋台など
プライベート…飲食店の店内など

屋台だと、事実上、路上で簡易な立て付けですので、
覗き見もしやすいですし、(誰も見ていなければ)通行人が店内に入って悪戯をするって、
結構簡単にできると思いますが、

屋内だと、覗き見も窓からに限られますし、出入口を通って店内に入ってからでないと、悪戯はできません。

FWが、出入口や、店内に案内する従業員
LBが、案内される部屋や座席等

に例えられると思います。

いずれも、実力行使すれば、店内に悪戯できることには変わりませんが、守りやすさはぜんぜん違いますよね。

1Like

Your answer might help someone💌