ユーザー名とパスワードで API を保護するために、Flask-HTTPAuth ( https://github.com/miguelgrinberg/Flask-HTTPAuth ) を使用しています。これはポート 8080 で実行されているため、VM でポートを開き、公開しました。API をより安全にするために他にできることはありますか?
ところで、スケーラブルなサーバーとして機能するために、Flask の前で Tornado を使用しています。また、API を使用しているのは私だけです。そのため、ユーザー名とパスワードのペアを 1 つ持つことが実行可能なオプションです。
ありがとう。
編集 - ポート 8080 をより安全にするために、Windows ファイアウォールでできることはありますか?
以下に、私が目にするいくつかのリスク (順不同) と、それらを軽減する方法を示します。
サーバーに悪用可能なセキュリティ バグがある場合、またはその他の方法で構成が誤っている場合、誰かがマシンにアクセスし、データベースにアクセスできるようになる可能性があります。これを防ぐためのベスト プラクティスには、セキュリティ アップデートを自動的に適用する、NDS を使用するなどがあります (企業ネットワークの背後にいることで、かなりの保護が得られるようです)。
HTTP 基本認証は平文で送信されるため、理論的には、ネットワーク内の誰でもネットワーク トラフィックを傍受し、パスワードを盗み、マシン自体に接続することができます。ここでのベスト プラクティスは、HTTPS およびその他のプロトコルを認証に使用することです。ここでのニーズは、この情報を誰から保護しようとしているかにかかっています。
どの API もシステムへの入力を提供するため、脆弱性につながる可能性があります。SQL インジェクション攻撃は、データベースを攻撃する際の一般的な攻撃です。未加工の SQL クエリを実行せず、他のベスト プラクティス (境界チェックなど) を実行するようにしてください。
パスワードがなければ、悪意のあるユーザーは、うまく機能する組み合わせが見つかるまで、さまざまな組み合わせを試し続けることができます。ここでの解決策には、強力なパスワードの使用、スロットリングの実装、およびブルート フォース攻撃を検出するためのログ記録が含まれます。ここでの他の攻撃には、情報の漏えいが含まれます (パスワードの多くが間違っていると、より速く返され、正しいパスワードをより速く推測できるようになるなど)。
あなたのユースケース（企業アカウントの背後にある単一ユーザーアクセス）の場合、http基本認証はおそらく合理的なことだと思います。決定事項は、1) ネットワーク上の他のユーザーをどの程度信頼しているか、2) 保護しようとしているデータ (クレジット カードや健康情報など) がどの程度興味深いものであるかということです。
データを安全に保つために企業ネットワークを信頼していない場合、またはより多層的な防御を求めている場合は、パスワードの盗聴を防ぐために https を使用してから、強力なパスワードを使用することを検討してください。