ウェブサイトで実行中のコードを証明することは変更されていません
セキュリティ関連のコードを含むWebサイトの背後で実行されているコードが公開されたものと同じであることをユーザーに証明できますか？
現在、いくつかの新しいプロジェクトのアイデアを検討しています。1つは、安全なコミュニケーションに関するものです。ユーザーおよびより重要なセキュリティ専門家がレビューできるように、それをオープンソースにしたいと思います。これはうまくいけば、提供されたコードが安全であることを証明するのに成功するかもしれませんしかし、ユーザーはこのレビューされたコードが本当にWebサイトで実行されていることをどのように確信できますか？
私はセキュリティ関連の作業を行うファイルの一種のハッシュを提供し、それを印刷することを考えましたが、そのハッシュは簡単に静的に印刷でき、実際の確実性は提供されません。公開されたソースからコンパイルして比較できるアプリでそれを行うのは簡単ですが、ウェブサイトには適用できません。証明書は、サイトを運営しているのが誰であるかを証明するだけかもしれませんが、オペレーターが信頼できるかどうかはわかりません。
どんな種類のユーザーでも、信仰の飛躍をせずに保証できますか？
すべての現実において、システムがすべての攻撃から完全に安全であることを実際に証明することはできません。 証明可能なセキュリティ 新しい攻撃が定期的に開発されるため、本当に完璧になることはありません。セキュリティは新しい分野であり、ソフトウェアが悪用されるすべての方法を実際に知っているわけではありません。セキュリティを目的としたオープンソースのプロジェクトがあり、これを行う主な理由は2つあります。
一部の企業は、セキュリティを「調達」し、バグ報奨金プログラムを提供しています。 Mozillaはこのモデルで最も成功しているものの1つであり、そのすべてのアプリケーションとインフラストラクチャはオープンソースです。私はそれらのインフラストラクチャに4つの重大な脆弱性を発見し、これらの発見のために$ 3,000を収集しました。 Mozillaをより安全にすることができてうれしいです。これらの賞金を集めるのは簡単ではありません。バグ報奨金プログラムは、バグの狩猟を激しく競争させます。
アプリケーションの一部をオープンソースにするプロジェクトもあり、ユーザーはソフトウェアが実際に安全であることを相互依存的に確認できます。これの良い例はWhisper Systems（現在はTwitterの一部）とそのモバイル製品 RedPhone です。 HushMailもオープンソースです の一部はこのためです。
特定の質問または状況にこれが当てはまるかどうかはわかりませんが、title質問の。これを回答として投稿します。これは、（一般に）許可されていないコードがWebサーバー上にあるという問題が、私が知っているどのガイダンスでも十分にカバーされていないためです。この答えがあなたより私たちに似た状況にある他の人に役立つことを願っています。
100％確実であるとは限りませんが、ツールによって強化された安全な開発ライフサイクルは、支援に大きく役立ちます。それは労働集約的で、ログの手動チェック、または少なくとも一部の人間の操作が含まれる可能性がありますが、機密データと、いずれかのアプローチを実装するための予算がある場合は、IMOに取り組む価値があります。
サーバーに公開されたコードが承認され、レビューされたコードであることを確認するためのプロセスが用意されています。製品をリストアップするつもりはありませんが、手順とポリシーの概要は次のとおりです。
ポリシー：
- 開発者は、ライブシステム、期間にアクセスできません。開発者はコードをサーバーにプッシュできません。コードは、開発以外の指定されたチームによってプッシュされる必要があります。
- すべての変更が追跡されます（ソース管理）
- すべての変更は、公開する前に確認する必要があります。 （レビューは文書化され、レビュー担当者と開発者によって署名されます。）
- コードレビューは、公開が承認されている特定のソースコードのリビジョン番号を指定します。
- コードを公開するチームは、自動化されたビルド/デプロイメントスクリプトを介して、ソース管理から直接コードを公開します。彼らは単にリビジョン番号とタグを提供します。このスクリプトは、ソース管理の適切な場所からコードを取得し、それをライブサーバーにプッシュする役割を果たします。彼らは他のことをする方法を知りません。
これを実施するのに役立つツール：
- ファイルの変更をログに記録するソフトウェアがWebサーバーで実行されています。
- コードの変更により、セキュリティ管理者はフラグを立てます。セキュリティ管理者は、プロセスによって変更が承認、レビュー、および実装されたことを確認します。
- これは、不正なインサイダーまたはコードのアップロードによってサーバーに到達する可能性のあるコードをキャッチするのに役立ちます。
- ファイル/ディレクトリの違いを比較できるソフトウェアもあります。 （ 可能なツールはこちら ）これらのツールを使用して、「既知の正常な」公開されたコードのセットをスキャンし、ライブサーバーと比較できます。この場合の「既知」は、ソース管理から直接レビュー/承認されたリビジョンにあるコードです。
- これらのツールの多くはスクリプト化できます。
- 私たちはこれを実装していませんが、ソース管理からコードをチェックアウトし、スクリプトを使用して自動的に比較を行い、違いが検出された場合は特定の人にメールを送信するビルドサーバー構成を用意するという考えをいじっています。紙の上では、これを行う方法を理解しましたが、まだテスト/実装するまでには至っていません。
もちろん、これは私たちの開発/リスク管理/展開プロセスの完全なものではありませんが、承認されたコードが実際にライブサーバーに配置されていることを確認することを扱う部分を強調しています。継続的な自動ペンテストや、お客様へのリスクを最小限に抑えるために採用している他の多くの対策を省いています。
それはまた、誰にでもできることではありません。断固とした攻撃者が悪用できるホールがあります。たとえば、管理者が実際に変更をレビューして承認を確認していない場合、プロセスは機能しません。また、明らかにタイムラグがあります-セキュリティ担当者は24時間年中無休で変更を監視できないため、不在の場合、誰かがサーバー上で不正なコードを取得し、それが発生するまでそこにいる可能性があります。管理者が仕事に戻っています。
別の方法として、事前に決定され、事前に承認されたタグから、ビルドサーバーにx時間ごとにWebサイト全体を自動的に公開するというアイデアを利用しました。このようにして、不正なコードがそこに出たとしても、x時間ごとに自動的に消去されます。しかし、そのアプローチには明らかな問題があり、まだそのルートに進む準備ができていません。
私たちのすべての作業が愚かであり、私たちがそれを間違っている可能性は十分にありますが、この特定の問題について、私たちが最善を尽くして混乱しているガイダンスはほとんどありません。このプロセスは、特定の環境とビジネスモデルにも基づいています。 （私たち自身のWebサイト、自己ホスト型、開発チーム全体、ビジネスユニット、およびネットワーク管理者を維持することはすべて社内で行われます。）これはおそらく、別の状況の誰にも当てはまりません。うまくいけば、他の誰かがより効率的でよりうまく機能する他のアプローチを持っています。
したがって、他の回答と一致して、無許可のコードがサーバーに到達することを確実にする100％確実な方法はありません。だからといって、できることをすべてやめてはいけません。そして、あなたが何かをしていることを文書化してユーザーに示すことができれば、ユーザーの信頼を築くための長い道のりを行くでしょう。あなたが計画/プロセスの潜在的な穴について正直であるならば、あなたはおそらく彼らの信頼をさらに得るでしょう。ポイントは、理由、予算、時間、および利用可能なツールの制約の範囲内で、できる限りのことを行うことです。
ハッシュ関数のように、探している種類の証明を提供できる技術的なツールはありません。クライアントへの送信内容に関係なく、サーバーは常に正規のWebサイトから予期される正確な値を送信し、その後すぐに別のコードに切り替えることができます。
mightとは auditors です。あなたとあなたの従業員がサーバーが本当にあなたのコードを実行し、他のものではないことを確認する方法に関する詳細な手順を公開します。手順には、パスワードポリシー、メンテナンスルール、コードレビュー、ホスティングサービスの物理的セキュリティ、従業員の犯罪歴と借金の状態のスクリーニング、その他の何十億ものポイントが含まれます。 次に、監査会社に支払い、手順を検査し、手順に従っているかどうかを人々に送信します。そして最後に、あなたが本当にすべての手順に従っていることを伝えるレポートを書きます。これは、Webサイトが実際に必要なコードを実行していることを証明するものではありませんが、少なくともその目標に向けてかなりの努力をしたことを示しています。
正式には、このプロセスは WebTrust と呼ばれます。高いです。
短い答えはノーです。
常にどこかに穴が開いていますが、サービスが安全で、特定の状況でクライアントを強制的に実行できる場合は、リスクを最小限に抑えることができます。常にリスクが存在します。知らないことが害を及ぼす可能性があるため、リスクを認識してください。
できません。
原則として、リモート認証（Trusted Computingの機能であり、WebサーバーのTPMに依存）を使用して、Webサーバーに実行中のコードを「証明」（「証明」）させ、クライアントがこれを確認できます。証明。ただし、実際には、リモート認証はこの目的に使用するには難しすぎます。実用的な障壁が多すぎます。
したがって、Webサイトで実行されているコードが変更されていないことを証明する方法はありません。代わりに、攻撃者が最初にコードを変更する機会を制限するために、できるだけWebサーバーを保護する必要があります。
言い換えると、検出/検証ではなく防止に焦点を当てます。これは、防止が扱いやすいためです。
ファイル整合性監視ソリューション（TripWireなど）を内部的に信頼できる場合は、信頼できるサードパーティを介して同様のものを適用しようとすることができます。
あなたはインターネット上のどこかにあなたのファイルの許可されたハッシュを公開します。
Webサイト管理者がサーバーにソフトウェアをインストールします。サーバーは信頼できるサードパーティによって監視されています。信頼できるサードパーティは、ファイル整合性監視ソフトウェアをインストールします。
監視会社は、初期インストールが承認済みのハッシュと一致することを証明できます。サードパーティの監視会社がFIMツールを制御および監視し、ハッシュが変更された場合、または準拠しなくなった場合は、サイトのどこかにレポートします。
サードパーティを信頼し、サードパーティがエンドユーザーにそれらを信頼させるための合理的な管理を行うことができる場合、外部の人が監視しています。エンドユーザーの恐怖は、あなたが自己報告した場合、あなたが彼らに害を与えるようなあなたが行った変更を報告しないことに関心があると思います。ある意味では、これはAVとPentestの会社が最後のセキュリティチェックについて話している顧客のサイトにそれらの小さなバッジを付けたときにやっていることと多少似ていると思います。
別の可能性としては、アプレットベースの場合、ある種のコード署名があり、エンドユーザーが特定のソースからの既知のコードを使用していることをエンドユーザーが確認できるようにします。バックエンドで署名されたコードをチェックする可能性がありますが、コンパイルされていないコードでは問題が発生する可能性があり、Webサーバー自体を信頼したくないため、サードパーティによる確認が必要になる可能性があります。常に嘘をつくか、MitMへのプロキシを介して答えを渡すことができます。