「ALBでHTTPS化したのに、なぜ後ろにいるECSコンテナはポート80（HTTP）のままで通信できるんだろう？」

この一見不思議な挙動は、ALBが持つ2つの重要な役割を理解することで、スッキリと解決します。今回は、このALBの「魔法」の仕組みを、セキュリティグループの設定から紐解いていきましょう。

最終的な構成：安全な3層アーキテクチャ

まず、私たちが目指すのは、セキュリティと可用性のベストプラクティスに基づいた、以下のような3層アーキテクチャです。

• Web層: ALBがインターネットからのリクエストをすべて受け付けます。
• AP層: ECSコンテナがプライベートな領域でアプリケーションを動かします。
• DB層: RDSがさらに内側のプライベートな領域でデータを安全に保管します。

この構成のセキュリティの肝は「ECSはALBからの通信しか受け付けない」というルールです。これを実現するのが、次に説明するセキュリティグループです。

門番の役割を担う「セキュリティグループ」

セキュリティグループは、リソースのドアを守る「バーチャルな門番」です。今回は3人の門番を配置します。

1. ALBの門番: インターネットからの訪問者（ポート80, 443）を全員受け入れます。
2. ECSの門番: ALBの門番から紹介された人（ALBからのトラフィック）だけを通します。それ以外の人は全員お断りです。
3. RDSの門番: ECSの門番から紹介された人（ECSからのトラフィック）だけを通します。

この連携により、たとえ攻撃者がECSに直接アクセスしようとしても、門前払いされる仕組みが完成します。

ALBがこなす2つの全く異なる仕事

さて、ここからが本題です。ユーザーがhttp://でアクセスしてきた時に、ALBとコンテナの間で何が起きているのでしょうか。実は、これは2段階の独立した処理になっています。

ポイントは役割が2つ存在するということです。

ブラウザへの「リダイレクト指示」

最初のやり取りは、ユーザーのブラウザとALBの間だけで完結します。

1. ユーザー: ブラウザで http://example.com (ポート80) にアクセス。
2. ALB (ポート80の受付係): リクエストを受け取ると、中身は見ずにこう応答します。「すみません、こちらの窓口は安全ではありません。向かいにある安全な443番の窓口へ行き直してください」。これがHTTP 301リダイレクトです。

この時点では、リクエストはまだECSコンテナには一切届いていません。

ステップ2：コンテナへの「リクエスト転送」

ブラウザはALBからの指示に従い、今度は最初から安全な窓口へ向かいます。

1. ユーザー: ブラウザが自動的に https://example.com (ポート443) に新しいリクエストを送信します。
2. ALB (ポート443の受付係):
   • 暗号化されたリクエストを受け取り、持っているSSL証明書を使って通信を復号します（SSL/TLS終端）。
   • 安全な平文になったリクエストを、宛先であるECSコンテナのポート80へ転送（フォワード）します。
3. ECSコンテナ (ポート80): ALBから来た通常のHTTPリクエストを受け取り、処理を実行します。

このように、ALBはユーザーを正しい入口へ案内する「案内係」の仕事と、リクエストを内部の担当者へ届ける「取次係」の仕事という、2つの全く異なる役割をこなしているのです。

コンテナからすれば、常にALBという信頼できる取次係から、暗号化が解かれた分かりやすいリクエストが届くだけなので、ポート80で待ち受けていれば良い、というわけです。

非常に便利ですね。。

CDKの実装

SecurityGroup の実装

// ALB用セキュリティグループ
const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSg', { vpc });
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'Allow HTTP');
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443), 'Allow HTTPS');

// ECS用セキュリティグループ
const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSg', { vpc });
// ALBからの通信のみを、コンテナのポート80で許可
ecsSecurityGroup.addIngressRule(
    albSecurityGroup,
    ec2.Port.tcp(80),
    'Allow traffic only from ALB'
);

ALBリスナー

// ALB本体を作成
const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
    vpc,
    internetFacing: true,
    securityGroup: albSecurityGroup,
});

// HTTPリスナー (ポート80): HTTPSへリダイレクトするだけ
alb.addListener('HttpListener', {
    port: 80,
    defaultAction: elbv2.ListenerAction.redirect({
        protocol: 'HTTPS',
        port: '443',
        permanent: true,
    }),
});

// HTTPSリスナー (ポート443): ECSへリクエストを転送する
alb.addListener('HttpsListener', {
    port: 443,
    certificates: [certificate], // ACMで発行した証明書
    defaultAction: elbv2.ListenerAction.forward([ecsTargetGroup]), // ECSのターゲットグループ
});

まとめ

• ALBのHTTP→HTTPSリダイレクトは、「リダイレクト指示」と「リクエスト転送」の2段階で行われる。
• SSL/TLSによる暗号化・復号の処理はALBがすべて肩代わりしてくれる（SSL/TLS終端）。
• コンテナは、ALBから転送されてくる暗号化されていないHTTPリクエストを受け取るだけで良い。
• セキュリティグループを正しく設定することで、この安全な通信経路が完成する。

役割が2つあることが分からなければ理解できなかったなぁ。

参考記事

この記事では、これらのプロトコルの基本、特にメソッド、ステータスコード、ヘッダー、クッキーという要素に焦点を当て、それらがどのようにWebの基盤となっているかを掘り下げます。

さらに、HTTPSがHTTPにセキュリティ層を追加する方法と、その重要性についても触れていこうと思いまっす

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

1. HTTPSを使用する
   データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
   これにより、中間者攻撃（MITM）のリスクを減らすことができます。
2. CORSポリシーを適切に設定する
   クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
   不適切なCORS設定は、セキュリティリスクを招く可能性があります。
3. 認証と認可
   JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
   また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
4. 入力の検証とサニタイズ
    SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
5. 依存関係のセキュリティ
   使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

1. コードの分割
   ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
   これにより、初期ロード時間を短縮できます。
2. キャッシュ戦略の利用
   静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
   ブラウザのキャッシュやCDNの利用が有効です。
3. 遅延ローディング（Lazy Loading）
    画像やコンポーネントなど、必要になるまでロードしないようにします。
   これにより、初期ロードのパフォーマンスを向上させることができます。
4. APIの最適化
   不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
   また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
5. フロントエンドのパフォーマンス最適化
   Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

Webの世界は複雑で、ちょっとしたことが大きな違いを生むんですよね。CORSもその一つ。

さあ、一緒にCORSを理解してきましょう〜

CORSって何？

まず、CORSって何？って話から始めます。

CORSは、Webページが異なるオリジン（つまり、異なるドメイン、プロトコル、またはポート）のリソースにアクセスする際のセキュリティメカニズムです。

つまり、あなたのサイトが他のサイトのデータを安全に扱うためのルールのこと。これがないと、セキュリティリスクが高まります。

なぜCORSが必要なの？

Webはオープンでつながっているけど、同時にセキュリティも重要です。

例えば、あなたがログインしているサイトAから、悪意のあるサイトBがデータを盗もうとするといったリスクがあります。

CORSは、このような不正なアクセスを防ぐために存在しているんです。
安全なWebのためには、必要不可欠なんですよ。

CORSの仕組み

CORSの基本は「信頼できるオリジンからのリクエストのみ許可する」ということ。

これは、サーバー側で設定され、ブラウザがこの設定に従います。

サーバーは、リクエストが来たときに「このオリジンからのリクエストはOKかな？」とチェック。

OKならリソースを提供し、ダメなら拒否。これで、安全にデータのやりとりができるようになります。

簡単なCORSの例

例えば、あなたのサイト（example.com）が、他のサイト（api.example.com）からデータを取得したい場合があるとします。

もし、api.example.comがCORSでexample.comを許可していれば、問題なくデータのやりとりができます。

でも、許可されていなければ、「CORSエラー」が発生してアクセスできないんです。

CORSをどう扱う？

開発者としては、CORSは頭痛の種になることも。

しかし、適切に設定することでセキュリティを確保しつつ、必要なデータ交換も可能になります。サーバーの設定を見直したり、必要に応じてオリジンを許可リストに追加することが大切です。

設定方法

素のPHP

※WEBサーバーにて設定することも可能ですが、今回はPHPでの実装を想定。

header("Access-Control-Allow-Origin: http://example.com");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
header("Access-Control-Allow-Headers: Content-Type, X-Requested-With");

/**
* - http://example.com からのアクセスを許可
* - 許可メソッドは GET, POST, PUT, DELETE
* - リクエスト中に許可されるHTTPヘッダー
*     - Content-Type（リソースのメディアタイプ
*     - X-Requested-With（通常、Ajaxリクエストを識別するために使用される）
*/

Laravel

※Laravel 7.x以降ではデフォルトでCORS設定が組み込まれているっぽい。

return [
    'paths' => ['api/*'],
    'allowed_methods' => ['*'],
    'allowed_origins' => ['http://example.com'],
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => [],
    'max_age' => 0,
    'supports_credentials' => false,

    /**
     * - http://example.com からのアクセスを許可
     *   'allowed_origins' => ['http://example.com']
     *   この設定は、http://example.com からのリクエストを許可します。
     * 
     * - 許可されるHTTPメソッド
     *   'allowed_methods' => ['*']
     *   この設定は、すべてのHTTPメソッドを許可します。特定のメソッドのみを許可する場合は、
     *   ['GET', 'POST', 'PUT', 'DELETE'] のように配列を編集します。
     * 
     * - 許可されるHTTPヘッダー
     *   'allowed_headers' => ['*']
     *   この設定は、すべてのHTTPヘッダーを許可します。特定のヘッダーのみを許可する場合は、
     *   必要なヘッダーを配列に追加します。
     */
];

まとめ

CORSは、Webの安全性を保つための重要なメカニズム。最初は複雑に感じるかもしれませんが、基本を理解すれば、より安全で効果的なWebアプリケーション開発が可能になります。

これにてCORSの基本を何となく理解！