セキュリティ

暗号化は、鍵を使ってデータを第三者に読めない形（暗号文）にすること、復号はそれを元に戻すことです。共通鍵暗号（AESなど）は同じ鍵で暗号化と復号をし、高速ですが、相手に鍵を安全に渡すのが課題です。公開鍵暗号（RSA、楕円曲線暗号など）は、数学的に対になった公開鍵と秘密鍵を使います。公開鍵は誰に配ってもよく、秘密鍵は持ち主だけが持ちます。

「どちらの鍵で何をするか」を逆に覚えないように、暗号化は相手の公開鍵、署名は自分の秘密鍵と覚える。

公開されたWebサイトのTLS証明書の最長有効期間は、CA/Browser Forumの決定で段階的に短くなっています。2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日になります。手作業での更新は現実的でなくなるので、自動更新が前提です。

有効期間が短くなるほど、自動化していない証明書が障害の原因になる。

SREが関わる場面では、AWSやGitHub、監視ツールなどへのログインを、社内のIDプロバイダ（Google Workspace、Microsoft Entra ID、Oktaなど）にSSOでまとめ、MFAを必須にします。人の入退社やチーム異動のたびに各サービスの権限を手で直すのはミスの元なので、グループとSCIMで自動化します。アプリの利用者向けには、パスワードに加えてパスキーやMFAを提供します。

HTTPでの認証情報のやりとり（Cookie、セッション、トークン、OAuth）は認証と状態管理で解説しています。

責任共有モデルでは、データセンターや物理サーバー、仮想化の基盤などの「クラウドそのもの」はAWSが守り、その上に置くデータ、アクセス権、OSやアプリの設定などの「クラウドの中」は利用者が守ります。EC2ならOSのパッチまで利用者の責任ですが、RDSやLambdaのようなマネージドサービスではAWSの範囲が広がります。ただし、データと誰がアクセスできるか（IAM）は、どのサービスでも必ず利用者の責任です。

AWSのセキュリティ設計で最初に効くのがマルチアカウントです。AWSアカウントの境界は最も強い隔離なので、本番・開発・セキュリティ用などに分け、AWS Organizationsでまとめて管理します。ログを集める専用のアカウントを作り、本番の管理者でもログを消せないようにします。組織全体にはSCP（サービスコントロールポリシー）で「これだけは絶対にさせない」上限をかけます。

マネージドサービスを選ぶことは、守る範囲をAWSに移すことでもある。

アカウントの壁が一番強い。SCPで組織全体の「やってはいけないこと」を固定する。

AWSが推奨するマルチアカウント構成では、管理アカウントは組織の管理と請求だけに使い、ワークロードを置きません。その下にOU（組織単位）を作り、アカウントを用途ごとにまとめます。AWS Control Towerを使うと、ログ用と監査用のアカウント、基本のガードレール、アカウントを作る仕組み（Account Factory）を、この構成でまとめて用意できます。

人のアクセスはIAM Identity Centerにまとめ、どのアカウントにどの権限セットで入れるかをグループで管理します。GuardDutyやSecurity HubはAuditアカウントを委任管理者にして、組織の全アカウントで自動的に有効になるようにします。

OUは「組織図」ではなく「かけたいルールの違い」で分ける。

IAMでは、ユーザーやロールにポリシー（JSONで書いた許可・拒否のルール）を付けて権限を与えます。人もアプリも、長期間有効なアクセスキーではなく、ロールを引き受けて得る一時的な認証情報を使うのが基本です。EC2やLambda、ECSのタスク、EKSのPodにはロールを割り当て、GitHub ActionsなどのCIからはOIDCでロールを引き受けます。

ポリシーの評価にはルールがあります。どこかに明示的なDenyがあれば必ず拒否、SCPや権限境界の枠の外も拒否、そのうえでどこかにAllowがあれば許可、どこにもなければ暗黙的に拒否です。S3のバケットポリシーのように、リソース側に付けるポリシーもあります。

権限がないとき、まず「どこかにDenyがないか」、次に「SCPで止められていないか」を確認する。

AWS の中のサーバーは、何重もの「関所」で守ります。サーバーのネットワークのつなぎ口（ENI）ごとのセキュリティグループ、サブネットの出入口のネットワークACL、HTTP の中身を見る WAF など、置く場所と見るものが違う仕組みを組み合わせます。

どれか1つの設定漏れで「つながらない」障害になり、逆に開けすぎると攻撃の入口になります。それぞれがどこで、何を基準に止めるかを知っておくと、つながらないときに疑う場所を順に切り分けられます。

実務では、SGを主な防御にし、送信元をIPアドレスではなく「ALBのSGから」「アプリのSGから」のようにSGで指定すると、台数が増えても設定を変えずに済みます。NACLは、特定のIPからの通信をまとめて遮断したいときなど、補助的に使うことが多いです。SSHの22番ポートを全世界に開けるのは避け、サーバーへのログインはSession Managerを使います。

「返りの通信が届かない」障害は、ステートレスなNACLの設定漏れが典型。

下の「ブラウザで試す」の図では、パブリックとプライベートのサブネットに分けた VPC で、アプリが NAT ゲートウェイを通って外へ出られても外からは入れないところ、DB のセキュリティグループに許可がないと SYN が捨てられてタイムアウトになるところ（「Connection refused」との違い）、S3 へはゲートウェイ型の VPC エンドポイントで NAT を通らずに届くところを順に見られます。表のうち SG・プライベートサブネット・VPC エンドポイントが出てくるので、パケットがどこで止まるかに注目してください（NACL と WAF はこの図には出てきません）。

WAF（Web Application Firewall）は、HTTPのリクエストの中身を見て、SQLインジェクションやクロスサイトスクリプティングなどの攻撃パターン、悪質なボット、特定の国やIPからのアクセス、短時間の大量アクセスを止めます。AWS WAFは、CloudFront、ALB、API Gateway、AppSyncなどに付けられます。

WAFを入れたら、「WAFを通らずにオリジンに届く経路がないか」を必ず確認する。

踏み台サーバー（Bastion）は、インターネットから直接入れないプライベートなサーバーやDBに入るために、公開側に1台だけ置く中継用のサーバーです。運用者はまず踏み台にSSHで入り、そこから内側に入ります。ただし、SSHの22番ポートを公開し続けることになり、鍵の配布と回収、誰が何をしたかの記録が課題でした。

AWSではSystems ManagerのSession Managerを使うと、サーバー側のエージェントが内側からAWSに接続するので、受信のポートを開けずにシェルに入れます。権限はIAMで管理でき、MFAやSSOと組み合わせられ、操作のログをS3やCloudWatch Logsに残せます。

どの方法でも、本番に入る操作は「誰が、いつ、何のために」を記録し、必要なときだけ一時的に権限を与える（Just-In-Timeアクセス）運用にすると、事故や不正を防げます。

「22番を開けない」「鍵を配らない」「操作を記録する」の3つを同時に満たせる。

どれも組織全体で有効にして、監査用のアカウントに結果を集めるのが基本です。検知したら何をするかを手順書にしておき、たとえば「認証情報の漏えいが疑われたら、キーを無効化し、そのキーで行われた操作をCloudTrailで洗い出す」といった初動を決めておきます。誤検知が多いと誰も見なくなるので、通知する重要度を絞ることも大事です。

「集めて、絞って、すぐ動ける」形にしておかないと、検知しても誰も気づかない。

通信中の暗号化（in transit）は、ネットワーク上の盗聴や改ざんを防ぎます。HTTPSはHTTPをTLSで包んだものです。TLSは1.2以上を使い、古い1.0・1.1は無効にします。ロードバランサやCDNでTLSを終端すると、その先はいったん平文になるので、その区間も暗号化するか（再暗号化）、閉じたネットワークで守るかを決めておきます。ブラウザに「このサイトは必ずHTTPSで」と覚えさせるHSTSヘッダーも使います。

mTLS（相互TLS）は、サーバーだけでなくクライアントも証明書を出して、お互いを確認する方式です。サービス同士の通信で「相手が本当にそのサービスか」を確かめたいとき（サービスメッシュやゼロトラスト）に使います。

保存時の暗号化（at rest）は、ディスクやバックアップが盗まれても読めないようにします。AWSではEBS、S3、RDSなどで、KMSの鍵を使って暗号化できます。KMSはエンベロープ暗号化という方式で、データはデータキーで暗号化し、そのデータキーをKMSのマスターキーで暗号化して一緒に保存します。マスターキーはKMSの外に出ず、使える人をIAMで絞り、使用履歴はCloudTrailに残ります。

暗号化されていない区間がどこかを、構成図の上で説明できるようにしておく。

通常のTLSは「サーバーが本物か」だけを確かめる。mTLSは両方向。

マスターキーを外に出さずに大量のデータを速く暗号化できる。

Linuxでは、昔はroot（UID 0）かそれ以外かの2択でした。capabilitiesは、rootの権限を約40の能力に分け、プロセスに必要なものだけを与えられるようにした仕組みです。たとえば1024未満のポートで待ち受けるだけならCAP_NET_BIND_SERVICEだけを渡せば、rootで動かす必要はありません。

# Kubernetesの例：rootで動かさず、能力を全部削ってから必要なものだけ足す
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
  seccompProfile:
    type: RuntimeDefault

CAP_SYS_ADMINや特権モードは「ほぼroot」。コンテナに渡すと、ホストへの脱出の足がかりになる。

イメージ：ベースイメージは必要最小限のもの（distroless、slim、Alpineなど）を使い、入っている部品を減らして脆弱性の数そのものを減らします。依存ライブラリはバージョンを固定し、ビルドのたびに脆弱性スキャンとSBOMの作成を行います。パスワードやAPIキーをイメージに焼き込んではいけません（イメージを持っている人は誰でも取り出せます）。

レジストリ：ECRなどの非公開レジストリに置き、タグを不変（同じタグで上書きできない）にして、本番で動くイメージが勝手に差し替わらないようにします。プッシュ時と定期的なスキャンで、後から見つかったCVEにも気づけるようにします。可能ならイメージに署名し、デプロイ時に署名を確認します。

実行：コンテナはホストのカーネルを共有しているので、コンテナから抜け出されるとホスト全体が危険になります。そのため、rootで動かさない、特権モード（privileged）を使わない、Linuxのcapabilityを削る、ファイルシステムを読み取り専用にする、seccompで使えるシステムコールを絞る、といった方法で権限を最小にします。KubernetesではPod Security Standards（restricted）や、Kyverno・OPA Gatekeeperなどで危険な設定をデプロイ時に拒否します。

「スキャンして終わり」ではなく、デプロイ時の検査と実行時の制限・監視までつなげる。

どこか1枚が破られても、次の層で被害を止める。

ノードのロールを全Podで共有すると、1つの侵害が全権限の漏えいになる。

CVE（Common Vulnerabilities and Exposures）は、公開された脆弱性を世界中で同じ名前で呼ぶための識別番号です。MITREが運営するCVEプログラムのもと、ベンダーや研究機関などのCNA（採番機関）が番号を割り当てます。米国NISTのNVDや日本のJVNが、CVEに詳細や深刻度の情報を付けて公開しています。CVEは「何の脆弱性か」を特定する番号であって、危険度そのものではありません。

危険度はCVSS（共通脆弱性評価システム）で0.0〜10.0の点数にします。攻撃がネットワーク越しにできるか、認証が要るか、利用者の操作が要るか、機密性・完全性・可用性にどれだけ影響するか、などから計算します。ただしCVSSは「最悪の場合の深刻さ」なので、点数の高い順に全部すぐ直すのは現実的ではありません。

そこで実務では、実際に悪用が確認されているかを米国CISAのKEV（Known Exploited Vulnerabilities）カタログで、今後30日以内に悪用される確率をFIRSTのEPSSで確認し、さらに自社でその機能を使っているか、外部に露出しているかを合わせて優先度を決めます。どのライブラリのどのバージョンを使っているかを把握するために、SBOM（ソフトウェア部品表）を整備し、依存ライブラリやコンテナイメージを継続的にスキャンします。

CVEは「どの脆弱性か」を指す番号。危険度はCVSSで別に表す。

点数は最悪の場合の深刻さ。自社の状況で優先度は変わる。

5〜8が自社の仕事。検知を自動化し、評価の基準を事前に決めておく。

「CVSSが高い順」ではなく「悪用されやすく、外部に出ている順」に直す。