リバースプロキシのみでWebアプリケーションを保護する
パブリックHTTP API（いわゆるREST）を保護するために、クライアントは（OAuth 2.0）アクセストークンを検証し、HTTPリクエストを内部Webサービスに転送して処理する単純なHTTPリバースプロキシを実装するように求めています。
私のクライアントには「強力な」ネットワークレベルのセキュリティがあるという考えです。プロキシの背後にあるさまざまなWebアプリケーションは、外部からアクセスできないため、セキュリティ上の制約はありません。複数の内部サービスが相互に呼び出している場合、デバッグを簡単に維持したいと考えています。 TLSではなく、内部呼び出し用のプレーンhttp。
内部アプリケーションを「ワイドオープン」のままにしておくのはひどい考えだと思います。ネットワークに侵入できた攻撃者は、基本的に機密（クリアテキスト）の顧客データに無料でアクセスできるためです。 。運用の観点から見ると、プロキシからのACL（OAuthスコープ/ URLマッチング）などの細かい制約を適用し、新しいサービスがデプロイされたときに構成を最新に維持するのは面倒です。
私が見逃しているものが見えますか？アプリケーションレベルのセキュリティを実装するための追加の引数はありますか？
編集：私が明確に言及/説明しなかったいくつかの重要な詳細：
- ここで説明しているWebアプリケーション（セキュリティプロキシのみに隠れている）はすべてWebサービスです。
- ユーザーインターフェイス（パブリック/内部 "サイト"）を備えたWebアプリケーションは別のネットワークゾーンにあり、問題のWebサービスと比較して、適切なアプリケーションレベルのセキュリティを備えています。
私が言及した「強力な」ネットワークセキュリティは、ゾーン、エンドユーザー（および無許可の内部関係者）が理論的にはWebサービスに直接（プロキシ経由でのみ）アクセスできないことに関するものです。回答で述べられているように、マシンにアクセスするとき、opsはまだ何らかのルートを提供できると思います。
私の理解に基づいて、私はそれがひどい考えであることを証明するために内部ネットワークの中に入る必要さえないと思います。攻撃者（元従業員、サードパーティの請負業者、または不満を持つ既存の従業員である可能性があります）。この安全でない内部アプリケーションについて何らかのコンテキストを持つ内部ホストアドレスアプリケーションがホストされている場所など- 重要な機能アプリケーションの知識、アプリケーションの全体的な外観（これは明らかにフィッシングWebサイトの作成に役立ちます）、そしてもちろん、アプリケーションがWebアプリケーションの一般的な問題に対して脆弱です（特に Cross-Site Request Forgery ）。
よし。上記の仮定に基づいて、私は次の可能な攻撃を考えることができます：
CSRFの脆弱性を利用して、アプリケーションに状態変更要求を行う際に内部ユーザーをだまします。これ自体は、認証されたユーザーをだましてWebサイトにアクセスさせることで、アプリケーションの他の一般的な脆弱性を悪用するために使用できます。JavaScriptはyour payloadsを使用してアプリケーションへのリクエストを待機しますが、- 被害者のセッションCookie。コマンドインジェクション、SQLインジェクション、XSSなどのインジェクションペイロードを送信できます。攻撃面がわかっているため、それに応じてリクエストを作成できます。
アプリケーションで誤って設定されたJSONPまたはCORS実装を悪用しています。この場合も、CSRFの脆弱性を利用して、セッションCookieを使用して内部アプリケーションにリクエストを送信します。ただし、今回は、状態を変更するリクエストを実行する代わりに、悪意のあるJavaScriptがアプリケーションからの機密応答を読み取ります（JSONPとCORSのため）。詳細は here 、 here および here を参照してください。
内部ユーザーをフィッシングする（DNSキャッシュポイズニングを介している可能性があります）。これで、アプリケーションの外観がわかったので、フィッシングWebサイトを作成するか、アプリケーションのログインページだけを作成して、パブリックアドレスでホストすることができます。次に、ネットワーク内のエンタープライズDNSサーバーのDNSキャッシュを汚染するか、内部システムのホストファイルを変更するだけで（おそらく、それらをだましてマルウェアをダウンロードさせることにより）この最後のステップは、ネットワークの外部から悪用するのが少し難しいですが、私はあなたがアイデアを得ることを願っています。さらに読みたい場合のDNSキャッシュポイズニングの詳細： DNSおよびDNSキャッシュポイズニング 。 アプリケーションはTLSを介していない（認証なし）！
これは、一般的にあなたの状況にアプローチする方法です。
お店にご相談ください
アプリケーションのセキュリティについて説明するときに、クライアントが本当に関係しそうな3つの点があります。 （ユーザーが脚注である時間の90％）。
- IP（知的財産）。顧客が自分の秘密を競争相手に公開することを望んでいない。
- 画像。評判とイメージが一致していれば、企業はより良いセキュリティ対策にやる気を起こさせることができます。これは、クライアントが非常に競争の激しい環境にあり、違反によってユーザーが競争に押し寄せる可能性がある場合に特に当てはまります。
- お金。企業がお金を失うという脅威以上に行動する動機はありません。セキュリティでは、追加の外部支援を雇う時間と費用であり、コンプライアンスの状況では、さらに罰金が加算されます。
チームと話す
セキュリティの世界では、リスクは私たちがプレイするゲームであり、ビジネスに適応するよう説得することが私たちの仕事です。技術的な観点から、セキュリティチームの私たちは、このタイプのシナリオを「これIS SUCH A BASIC THING」と見なします。ビジネスの観点から、彼らは「私が実際に行う可能性は妥協する？」
私は明らかにクライアントやそのネットワークを知りませんが、これから私が始める方法の基本を説明します（質問をするときに批判的に聞かないようにしてください）：
- 彼らの「安全なネットワーク」はどのようなものですか？彼らはベストプラクティスを行っていますか？最新のものはありますか？
- 彼らはなぜセキュリティを適用したくないのですか？知識ベース？お金？あなたのケースではデバッグ。
- 何かをしない理由をより安全な方法で解決できますか？テスト環境でのデバッグが思い浮かびます。
最後に、そのレベルで話してください
スモールビジネスは、フォーチュン500でない大企業ではない中企業ではありません。すべてのレベルで欲望、ニーズ、機能があり、セキュリティアプライアンスでさらに50Kが必要であるとクライアントに伝えた場合、非常に消極的なビジネスを扱うことになります。
私が重点を置く3つのこと：
- 彼らの業界に話をしてください。医療業界が何かを行う方法を知ることはいいことですが、もし彼らが産業制御で働いていれば、彼らは気にしません。
- 彼らの利益率でスペック。これは、以前の会社の規模に関する声明に戻ります。ハンバーガーキングにはアップルのリソースがありません。
- 彼らの経験に話しかけてください。彼らの業界または競争に違反があった場合は、それに話しかけます。彼らは通常知っているでしょう（Wordは動き回ります）。もし彼らが聞いていないなら、それは彼らがターゲットにしている可能性があり、おそらくターゲットにしているコンセプトを強化します。
これがプロキシの問題に正確に対応しているわけではないことはわかっていますが、クライアントについて知らずにクライアントの詳細な状況を特定することはできません。
外部にも接続するブラウザを備えた内部ユーザーは、イントラネットと公衆インターネット間のルートを提供します。私は「これは内部のWebアプリですので心配しないでください」と私に言っている人々に常にこれを指摘しています。
あなたの場合はHTTPSが必要です。これは、ネットワークに侵入した誰かが言及する脅威から保護するだけでなく、侵入する必要のない悪意のある内部者からも保護します。httpsなしで機密データ自体を公開するほかに、資格情報をクリアテキスト、資格情報で公開しますこれにより、内部リソースへのアクセスがさらに増える可能性があります。ワイヤレスが内部で使用されている場合、問題はさらに悪化します。
これらのWebアプリの内部ユーザーはアクセス制御をまったく持っていないようです。アプリケーション自体にアクセス制御を組み込むべきだと思います。
デバッグを簡単にしたい場合は、セキュリティコントロールをオフにしたテスト環境を用意してください。
私たちのリバースプロキシ（ポンド）は、1つのセキュリティ機能を提供します。それは、外部クライアントとWebリソースの間の仲介者として機能します。これにより、アクセスポリシーを設定するために使用できます。これは、保護したい機密性の高い内部Webアプリケーションに対する保護レイヤーの1つですが、これが唯一のレイヤーであるとは思いません。
私はこの状況で個人的に3つのことを行います。
フィッシングの結果である主要な侵害の割合に関するデータをクライアントに示す（95〜97％のようなもの）
さらに、フィッシングが直接ネットワーク上のトラフィックをスニッフィングする攻撃者につながり、それらのサービスとの間でやり取りされるすべてのデータを表示できることを示します。
これらのWebサービスによって渡されているデータの量と質を特定し、攻撃者のトラフィックのスニッフィング時間に関連する潜在的なコストを定量化しようとするリスクモデルとともに、それらをクライアントに提示します。
これは主にSSLの欠如に関連していますが、あなたの状況を考えると、それが最も差し迫った問題であると思われます。
頑張って頑張ってください。消極的なクライアントにセキュリティを強調することがいかに難しいか理解しています。ただし、常にビジネス価値を高め、それをどのように行うことができるかを彼らに示すことを常に心に留めておく必要があります。
最も一般的なサイバー攻撃は、年次のベライゾン違反レポートに非常によくまとめられています。 http://www.verizonenterprise.com/DBIR/
そこに示されているように、フィッシングおよびクレデンシャルの盗難攻撃は、最も一般的な脅威の2つです。したがって、悪意のあるリンクを誰かが誤ってクリックして内部システムが危険にさらされた場合、攻撃者はネットワーク内に侵入し、そのシステムのサブネット上のすべての非TLSトラフィックを監視できる可能性があります。次に、攻撃者は資格情報を取得し、リバースプロキシを使用する必要なく内部でWebサーバーにアクセスする可能性があります。
また、資格情報を再利用する場合（一般的）、パスワードが平文で送信されていることに気付かない可能性があります。攻撃者は[〜＃〜] other [〜＃〜]システムでこれらの認証情報を使用する可能性があり、場合によっては成功する可能性があります。これにより、ビジネスが違反の可能性にさらされるだけでなく、発見された場合の責任も問われます（私は弁護士ではありません-弁護士や保険会社と相談してください）。
これがあなたの主張に役立つことを願っています。
最終的には、プロキシレベルで完全に承認されたアクションがバックエンドコンポーネントで予期しない動作を引き起こす可能性がある場合があります。 ifではなくwhenの問題です。これはひどい考えです。これに対するあなたの本能は正しいです。クライアントがこの道を進んではいけないことを納得させるために、できることは何でもしてください。