最近のリリースでは、4Dのセキュリティ機能が、特に証明書の分野で大幅に拡張されました。これには、クライアント・サーバー間通信のための自動生成証明書、ECDSA証明書のサポート、そして4D 20 R7では、エンジン・アプリケーションのクライアント・サーバー間通信のための認証局の検証が含まれます。最高レベルのセキュリティを要求する顧客もいるため、これらの機能の重要性が浮き彫りになっている。
しかし、セキュリティは複雑な場合があり、TLS/SSL接続の仕組みや証明書の役割について説明してほしいという要望がありました。したがって、新機能を掘り下げる前に、まず基本的なセキュリティの概念とその相互作用を分解しておくとよいだろう。
暗号化、認証、証明書
セキュリティの中心には、暗号化と認証という2つの重要な概念がある。暗号化はデータを暗号化することで保護し、サーバーとクライアント間の不正アクセスを防止します。一方、認証はクライアントとサーバーの両方が本人であることを保証します。証明書は、通信を暗号化するために使用される非公開の鍵と、認証に使用される公開証明書という2つの要素から構成されるため、この2つの概念をカバーしています（そのため、2つのファイルが存在します）。
対称暗号化
最も単純な暗号化は対称暗号化で、クライアントとサーバーは同じ鍵を共有して通信を暗号化する。対称暗号化は、暗号化と認証の両方が保証されるので有利です。サーバーは正しい鍵を使うので有効であり、クライアントも同じ理由で有効です。対称暗号化の主な欠点は、サーバーとクライアントの両方に鍵をコピーする必要があり、別の安全な通信チャネルが必要になることです。
非対称暗号化
非対称暗号化はインターネット上で広く使われており、クライアントとサーバーの両方が公開鍵と秘密鍵を持つというシンプルなコンセプトで動作する。公開鍵は通信を暗号化し、秘密鍵はそれを復号化する。公開鍵は暗号化のみを許可するため、サーバーとクライアントは傍受の可能性を気にすることなく、公開鍵を自由に配布することができる。秘密鍵がなければ、通信の復号は不可能である。
4Dでは、HTTPサーバー、HTTPクライアント、および4Dサーバーと4Dリモートの間の通信に非対称暗号化が使用されます。HTTPサーバーでは、証明書とそれに対応するキーをプロジェクトフォルダーに配置する必要があります。4D Server と 4D Remote 間の通信では、証明書と鍵は 4D Server の Resource フォルダに保存するか、4D Server が証明書を自動生成します。HTTP クライアントと 4D Remote は、証明書を自動生成します。
対称暗号化とは異なり、非対称暗号化は暗号化を保証しますが、認証は保証しません。つまり、通信先のサーバーが意図したサーバーであることを保証できません。この脆弱性は、サーバーのなりすましや中間者（MITM）攻撃（攻撃者がクライアントとサーバー間の通信を傍受すること）につながる可能性があります。
サーバなりすましやMITMの防止：認証局の検証
中間者（man-in-the-middle）攻撃を防ぐには、クライアントとサーバがお互いを認証する方法が必要です。クライアントの場合、ユーザを認証したいマシン以上のものとして、古典的なログイン/パスワードダイアログが一般的に使われます。
サーバーを認証する最も一般的な方法の1つは、信頼できる認証局が発行した証明書を使用することである。認証局は世界的に認知されたエンティティであり、その署名はウェブブラウザなどのアプリケーションに埋め込まれている。サーバーが認証局から発行された証明書を提示すると、クライアントは保存されている認証局の署名と証明書の署名を比較することで、その真正性を検証することができます。
4D 20 R7における認証局検証の導入
それでは、4D 20 R7の新機能である、エンジン付きアプリケーションの認証局検証について説明しましょう。このアップデートにより、4Dクライアントは4Dサーバーから受け取った証明書を検証することができるようになり、サーバーの身元を確認し、中間者攻撃（MITM）から保護することができます。
これを実装するには、クライアント・アプリケーションをビルドする際に、buildApp.4DSettingsファイルに2つの値を追加する必要があります：クライアント・アプリケーションでコピーされる、信頼できる認証局の署名を含むファイルの場所と、サーバー証明書のドメイン名です。この情報により、クライアント・アプリケーションは、サーバから送信された証明書が有効な認証局から発行されたものであること、およびドメイン名が期待されるものと一致していることを確認できます。不一致があれば、接続は拒否される。
複数のクライアントが関与するケースでは、各クライアント用に個別のアプリケーションを構築することは困難です。これに対処するために、有効なドメイン名のリストを提供することができる。この方法は、単一のドメイン名を指定するよりも安全性は低いが、中間者である可能性のある人がクライアントの1つから証明書を所有する必要があり、これは簡単には達成できない。この場合、4Dは証明書が有効な認証局から発行されたものであることのみをチェックする。
インターネットや他の信頼されていないネットワーク上で通信するアプリケーションにとって、この機能はクライアントとサーバーの通信に不可欠な保護レイヤーを提供します。
4Dフォーラムに質問を投稿してください。