俊敏な境界型セキュリティをNGINX App Protectが実現

Isaac Noumba of F5

Product Manager (Security)

July 15, 2020

コンピューターセキュリティにおいて、「境界」とは、アプリケーションをはじめとするインフラの構成要素の中に安全性が確保されている信頼される空間として「トラストゾーン」を確立するために概念上の区切りを示すラインのことを指します。

「城と堀」型のアプローチによる従来のインフラ環境では、境界によってイントラネット（内部ネットワーク）とエクストラネットまたはインターネットが区別されてきました。イントラネットは安全であると推定され、外部からのみ脅威が発生すると想定されていました。静的なセキュリティ対策が多く、パケットインスペクションとアクセス制御によってイントラネットの周囲に要塞を築くことが対策となっていました。

しかし、外部の攻撃者は次々に新たな攻撃方法を考案します。セキュリティ制御を回避してイントラネットのコンポーネントを侵害する手法や、イントラネットが安全であると考えられていたことを悪用して、外部からの攻撃を境界内からのリクエストのように偽装する手法が編み出されました。この状況に突き動かされる形で登場したゼロトラストのセキュリティモデルでは、信頼が確立されるよりも前にすべてのエンティティ（内部と外部の両方）を継続的に評価するというもものです。イントラネットは、もはや安全であるとは見なされなくなりました。

デジタルトランスフォーメーションや、マイクロサービスなどの最新のアプリケーションアーキテクチャーでも、セキュリティの新たな課題が発生しています。現在、多くの企業のアプリケーションが、パブリッククラウドにホストされているか、またはクラウドとオンプレミスのトポロジー全体に分散されています。つまり、アプリケーションを保護するセキュリティインフラは、もはやローカルの管理者の完全な制御下にはありません。その結果、多くの組織は個々のアプリケーション（または構造上の直接的な相互依存関係を持つアプリから成る小規模なグループ）に境界を設置するようになっています。次の図では、緑の点線が境界を表しています。

アーキテクチャーのモデルに関係なく、境界部分では、門番を意味する「ゲートキーパー」が着信するトラフィックを検査し、内部アプリを保護するセキュリティポリシーを適用します。このゲートキーパーはエッジとも呼ばれます。次の図は、一般的なデプロイメントとして3つのパターンを示しています。赤枠で囲まれたPROTECTがエッジを表しています。

Kubernetesフレームワークなどのコンテナ化されたアーキテクチャーでも、同じ概念が適用されます。Ingressコントローラーは、Kubernetesクラスター全体のエッジとして機能して、外部クライアントからのアクセスを管理し、クラスター内のKubernetesサービスへリクエストをルーティングします。ただし、次の図に示すように、クラスター内のより詳細なレベルで、ポッドごと、サービスごとにセキュリティポリシーを適用することが可能です。

• ポッドごとの保護（右側）では、1つ以上のコンテナにアプリまたはアプリコンポーネントを含むポッドが境界として定義されます。
• サービスごとの保護（左側）では、1つ以上のポッドを介してアプリのデプロイメントのインスタンスがサービスによって公開されます。サービスの背後で、これらのポッドを囲む境界が確立されます。

NGINX App Protectによる境界の保護

NGINX App Protectは、最新のアプリケーションセキュリティソリューションであり、市場をリードするF5のWebアプリケーションファイアウォール（WAF）テクノロジーに基づいて構築されています。NGINX App Protectを使用することで、俊敏性のあるアプリケーションの保護が可能になり、デプロイメント環境やアプリケーションアーキテクチャー（オンプレミス、クラウド、ハイブリッド、マイクロサービスベース、コンテナ化）に左右されない境界セキュリティを実現できます。詳細については、新製品NGINX App Protectの紹介：NGINX Plusに搭載された高度なF5のアプリケーションセキュリティをご覧ください。

NGINX App Protectを使用してエッジでセキュリティを実装することの主なメリットは、境界の外側でセキュリティ対策を実行できることです。基本的には、エッジでトラフィックのインスペクションとアクセス制御が行われることで、脅威が境界を通過する前に排除されます。エッジは、アプリケーションの直前に位置する最後のホップとして、アプリケーションに対する脅威の種類や、その数を確認するためにもっとも良い場所となります。

次の設定は、1つの境界内で個別にアクセスされる3つのアプリ（app1、 app2、app3）を保護するためのNGINX App Protectの構成を示しています。

load_module modules/ngx_http_app_protect_module.so;
error_log /var/log/nginx/error.log debug;

http {
    # Enable NGINX App Protect in 'http' context
    app_protect_enable on;

    # Enable remote logging
    app_protect_security_log_enable on;

    # Default JSON security policy
    app_protect_policy_file "/etc/nginx/NginxDefaultPolicy.json";

    # Set remote logging options (in referenced file) and log server IP address/port
    app_protect_security_log "/etc/nginx/log-default.json" syslog:server=127.0.0.1:515;

    server {
        listen      80;
        server_name app1.com;
        app_protect_policy_file "/etc/nginx/NginxApp1Policy.json"; # JSON policy for app1

        location / {
            proxy_pass http://www.app1.com:8080$request_uri;
        }
    }

    server {
        listen      80;
        server_name app2.com;
        app_protect_policy_file "/etc/nginx/NginxApp2Policy.json"; # JSON policy for app2

        location / {
            proxy_pass http://www.app2.com:8080$request_uri;
        }
    }

    server {
        listen      80;
        server_name app3.com;
        app_protect_policy_file "/etc/nginx/NginxApp3Policy.json"; # JSON policy for app3

        location / {
            proxy_pass http://www.app3.com:8080$request_uri;
        }
    }
}

次の設定は、境界内の単一のアプリケーションに埋め込まれ、このアプリケーションを介して提示されるapp1、app2、app3を保護するためのNGINX App Protectの構成を示しています。

load_module modules/ngx_http_app_protect_module.so;
error_log /var/log/nginx/error.log debug;

http {
    server {
        listen      80;
        server_name app.com;

        # Enable NGINX App Protect in 'http' context
        app_protect_enable on;

        # Enable remote logging
        app_protect_security_log_enable on;

        # Default JSON security policy
        app_protect_policy_file "/etc/nginx/NginxDefaultPolicy.json";

        # Set remote logging options (in referenced file) and log server IP address/port
        app_protect_security_log "/etc/nginx/log-default.json"
                                 syslog:server=10.1.20.6:5144;

        location / {
            # Main JSON policy file
            app_protect_policy_file "/etc/nginx/policy/policy_main.json";
            proxy_pass http://app.com$request_uri;
        }

        location /app1 {
            # JSON policy file for app1
            app_protect_policy_file "/etc/nginx/policy/policy_app1.json";
            proxy_pass http://app.com$request_uri;
        }

        location /app2 {
            # JSON policy file for app2
            app_protect_policy_file "/etc/nginx/policy/policy_app2.json";
            proxy_pass http://app.com$request_uri;
        }

        location /app3 {
            # JSON policy file for app3
            app_protect_policy_file "/etc/nginx/policy/policy_app3.json";
            proxy_pass http://app.com$request_uri;
        }
    }
}

各アプリのセキュリティ要件はそれぞれ異なるため、どちらの構成でもアプリごとにapp_protect_policy_fileディレクティブが使用され、個別のセキュリティポリシーが割り当てられます。

NGINX App Protectのその他の構成については、ドキュメントをご覧ください。

NGINX App ProtectによるCI/CDパイプラインの境界セキュリティ

NGINX App Protectは、先進的なアプリの拡張性と自動化におけるセキュリティの課題に対処できます。CI/CDパイプラインの複数の統合ポイントにNGINX App Protectを直接導入することで、コードにより近い場所でポッド、サービス、アプリケーションを保護できます。これによって、開発、運用、セキュリティの間にあるギャップを埋めることができます。

セキュリティをアプリケーション開発サイクルに直接統合することで、セキュリティテストを実行/自動化し、アプリケーションやアプリコンポーネントに対するセキュリティのリスクを検出できます。セキュリティポリシーの適用を定義し、セキュリティコンプライアンスの要件を満たさない場合にはアプリケーションの公開を取り消すことができます。公開前の新しいバージョンのアプリケーションにNGINX App Protectを統合すれば、事実上、セキュアなアプリケーションを継続的に提供できます。

NGINX App Protectで境界を保護しましょう

30日間のフリートライアルを利用して、NGINX App ProtectとNGINX Plusをお試しいただけます。また、詳細なユースケースなどのご相談などにも対応いたしますので、こちらからお問合せください。製品ドキュメントおよびF5のWebアプリおよびAPI保護ソリューションの詳細もぜひご参照ください。