サーバーバックエンドを保護する方法
私は2つの目的を果たすサーバーを開発しています。それは、データを使用および保守する人々のためのCMSと、モバイルアプリがこのデータを取得するためのWebサービスです。 AWSクラウド上で（Java/JSPを使用して）Tomcat 6を実行しているDebianサーバーで実行されます。
現在、サーバーはログイン/パスワードを使用して両方のケースでユーザーを識別しています。モバイルアプリの場合、ログイン/パスワードはアプリ内であり、アプリのすべてのインスタンスで共有されます。誰かがクライアントのネットワークトラフィックを調べ始めると、URL、ログイン、パスワードが表示され、URLにアクセスしてCMSにログインできます（または少なくともログインサービスに対してブルートフォース攻撃を開始できます）。 。
CMSを保護するための最良の方法は何ですか？私のアイデアはおおよそ次のとおりです。
- CMSを別のサーバーインスタンスと別のドメインに移動します。それでも、基盤となるDBはWebサービスと共有されます。
- サーバーのログインポイントを不明瞭にします。基本的にすべての無効なURLをログインページにリダイレクトする代わりに、それらを厳密に404に送信し、ログイン名をランダムに変更します。
- モバイルアプリがCMSでは機能しないログイン/パスワードを使用していることを確認し（CMSエディター/アプリユーザーに異なる役割を実装することにより）、（ブルートフォースなどの）攻撃に対するログインを強化します。
私が正しく理解している場合、CMSは2つのタイプのユーザーにサービスを提供します。
- アプリ以外のユーザー（ブラウザから直接CMSにアクセスするユーザーなど）。読み取りおよび書き込みアクセス。
- モバイルアプリユーザー。読み取りアクセスのみ。
システムの設計によると、アプリユーザーは、自分のアプリがCMSにログインするために（アプリにハードコーディングされているため）使用するユーザー/パスワードの組み合わせを見つけることができます。したがって、アプリユーザーがCMSのデータを操作できないようにするonlyことは、ユーザーがアプリを使用しているという事実です。
あなたの当面の懸念は、CMSでの役割の分離です。 JSPでセッションを使用している場合、これは簡単です（おそらく、ユーザーのロールを表し、すべての.jspでロールチェックを行う別の列をユーザーテーブルに追加します）。
CMSのログインポイントに関しては、それを不明瞭にすると一部のボットがだまされる可能性がありますが、これでは不十分です。 iptablesを使用してブルートフォース攻撃を阻止するか、Tomcatのログを監視して疑わしい動作を禁止するある種のデーモンを実装することができます（SSHブルートフォーサーを禁止するために使用した私の例： https://github.com/epadillas/ ssh_banhammer.py ）。
また、認証資格情報などの機密情報を扱う場合は、常にHTTPSを使用してください。
まず、SSL（https）を使用します。これにより、盗聴者がユーザーの資格情報を学習できなくなります。
サイト全体のSSL（https）の長所と短所は何ですか？ 、 HTTPSを介したHSTSの追加のセキュリティ 、 HTTPSのみのサイトの実装者向けのガイダンス（サーバーサイド） 。
ユーザーがダウンロードするモバイルアプリのコードにパスワードを埋め込んでいる場合、それは少し奇妙であり、良い習慣のようには聞こえません。これは事実上、誰もが見ることができるようにWebサイトにパスワードを設定することと同じです。誰でもアプリをダウンロードしてバイトを確認し、パスワードを見つけることができます。プログラムのバイナリに格納されているものを秘密として扱うべきではありません。
ユーザーが自分のパスワードをアプリに入力した場合、それをアプリのプライベートストレージに保存し、すべての接続で再利用しても問題ありません。または、アプリの初回起動時に秘密鍵を生成し、対応するクライアント証明書をサーバーに（ユーザーのパスワードで認証されたSSL接続を介して）安全に送信し、クライアント証明書でSSLを使用してモバイルを認証します。以降のすべての接続でクライアントをサーバーに接続します（したがって、ユーザーは自分のパスワードを再度入力する必要はありません）。
CMSのコンテンツが一般に公開されることを目的としている場合、コンテンツを表示するためのパスワードは少し無意味であるため、削除する必要があります。モバイルアプリが一般に公開されており、モバイルアプリを持っている誰もがCMSのコンテンツを読むことができる場合、CMSのコンテンツは一般に公開することを目的としています。
ユーザーがデータを取得するために使用する各ユーザーの「APIキー」を生成できるため、データが盗まれたり侵害されたりしても、CMSへのアクセスに使用できず、そこからリセットすることもできます。
また、ログインエンドポイントにリダイレクトするのではなく、エラー（401 Unauthorizedまたは403 Forbiddenなど）で無効なログインに応答する必要があります。
CMSにオプションのセキュリティレイヤーを追加する場合は、多要素認証を追加することをお勧めします（例 Google Authenticator ）。
これらとは別に、サーバーをブルートフォース攻撃（リクエストが繰り返し失敗した後にアドレスをブロックするか、ログインフォームにキャプチャを追加する）、さまざまな挿入（コード、特にSQLクエリを注意深くチェックする）および盗聴からサーバーを保護する必要があります（モバイルアプリとWebサービス間のトラフィックを暗号化し、CMSサーバーでSSLを使用します）。そして、明らかに、サードパーティのソフトウェアとライブラリを最新の状態に保ちます。
セキュリティ層は物理層からアプリケーション層に上がるため、環境は常に重要です。
Javaには独自のセキュリティがあるため、Javaとは異なります。 PHP、PythonまたはRuby。Javaはソースコードをコンパイルしており、静的言語です。OOアクセス修飾子はコードの一部の権利を分離し、ほとんどの場合、PHPで行うようにJavaでコードインジェクションを実行できないため、安全と見なされています。
基本的にそのようなアプリのために何をする必要があるか：
- まず、Tomcatを使用して、分離された異なるコンテキストでアプリケーションを分割する必要があります。 PHPまたはIISを使用すると、別のシステムユーザーでこれを実行できます。Tomcatでは、個別のアプリケーションをセットアップするだけです。2つのtomcatなどの仮想化によってそれらを分離することもできます。と2つのIP。
- 各アプリケーションはデータベースに異なるログインを使用する必要があり、必要な権限のみが必要です。たとえば、フロントエンドとバックエンドは異なるレベルを持つことができるため、フロントエンドでのSQLインジェクションはシステム全体を壊しません。すべて同じDBを使用している場合。ビューを使用してそれを行うことができます。
- すべてのログインとバックエンドユーザーセッションでHTTPSを使用していることを確認します
- あなたはmod_proxyでその前にModSecurityでApacheをインストールすることができます
- セッションがセキュアであることを確認してください。暗号的に安全なトークン
そして何より：
- フロントエンドユーザーとバックエンドユーザーは別々のテーブルに保持し、そのアクセスをフロントエンドまたはバックエンドに制限する必要があります。したがって、frotendに違反した場合、無害な列がいくつかある場合を除いて、データベースを変更することはできません。
- パスワードは最低でもソルトでハッシュする必要があります。
- 合理的なパスワードの回復。
また：
- SELinuxでマシンを保護してみてください
- 優れた復元力のあるIPTABLESファイアウォールを作成します-これ以上は、マシンのルート化を防ぎます
また、聴衆が多い場合：
- ログイン、登録、パスワード回復（およびレポート）を、ユーザーテーブルへの排他的な書き込みアクセス権を持つ別のTomcatに分離しますが、別のTomcatアプリケーションでも問題はありません。 Tomcatの各実行コンテキストが相互に設定ファイル/ dbパスワードを読み取れないことを確認してください。
これは私がこの議論の結果決定したことです。
- もちろん、すべてがHTTPS経由です。
- CMSとモバイルアプリユーザーの役割を分けて、アプリからのログイン/パスワードがCMSで役に立たないようにします。
- ブルートフォース/辞書攻撃対策を実施し、ログインサービスを強化します。
- あまりにも多くの攻撃者がCMSのログインドアをノックするのを防ぐ方法に関して「ベストプラクティス」はないようです-CMSとWSを異なるサーバー/ドメイン/ ...に分割するか、単にログインを「非表示」にしますURL、またはその両方、あるいは何でも-それはそれほど重要ではありません。