皆さんこんにちは！
東京はようやく猛暑が終わりそうですね。
例年に比べると比較的過ごしやすかった気もしますがいかがでしょうか。
もう9月になりますが今年も残り4か月頑張っていきましょう。
さて、前回までに人生を賭けた求人サービスを構築するために『PHP』『postgreSQL』『AWS』を選んだ理由や、
サービス名の由来、求職者様向け＆企業様向け機能のご紹介、面談の採用確率UP方法、
『PHP』『postgreSQL』『AWS』の実機練習用サイトをご紹介させていただき、
さらに『SQL』『PHP』『AWS』の基本的な操作方法とセキュリティについて書かせていただきました。
今回も調子に乗って
『postgreSQL』のセキュリティについて掘り下げていきます！
今日はセキュリティ編の第5回目として、
『AWSとpostgreSQL』について語ります。
実際の構成を考えると、PostgreSQL単体の設定だけでなく、
AWS側のネットワーク・IAM・Secrets・監視まで含めて考えるのが重要です。
RDSならPublic Accessを基本的にOFF
RDSならPublic Accessを基本的にOFF
RDSをインターネットから直接アクセス可能にするのではなく、Private Subnetに配置して、
EC2 / ECS
↓
Security Group
↓
RDS PostgreSQL
という形にします。
Security Groupで「誰が5432に接続できるか」を制限
例えば、
RDS Security Group
Inbound:
TCP 5432
Source: App Server Security Group
とします。
これは、
0.0.0.0/0 → 5432
よりはるかに安全です。
特に、
TCP 5432
Source: 0.0.0.0/0
になっていたら、優先的に見直した方がいいです。
DBパスワードをコードに書かない
例えばアプリケーションに、
DATABASE_PASSWORD = "MySecretPassword123"
のように書くのは避けます。
AWSなら AWS Secrets Manager などを利用して、
Application
│
│ IAM
▼
Secrets Manager
│
▼
DB password
という構成にできます。
これならGitHubなどにDBパスワードを置く必要がありません。
IAMとDB権限を分けて考える
AWSでは、
IAM
↓
AWSリソースへの権限
と、
PostgreSQL Role
↓
DB内の権限
は別物です。
例えば、
ECS Task
↓
IAM Role
↓
Secrets ManagerからDBパスワード取得
↓
PostgreSQL
↓
app_user
という設計にします。
そして app_user には必要なDB権限だけ与えます。
AWSとの関係性を考えて安全に運営している求人サービスは以下になります。
企業の方、エンジニアの方、どちらも使ってみてください！
▼求人マッチングサービス【ヴェテラン】
https://veteran-work.com/
「AWSじゃなくてAzuruだったらどうなるの！」
「ヴェテランってセキュリティどうなってるの？」
など質問やご意見いただけますとモチベーション爆上げします！
本日もお疲れ様でした。
明日もコツコツと頑張りましょう。