開発者が会社のクレジットカードの詳細やその他の秘密データにアクセスするのを阻止するもの
まず、これが何度も議論されてすみませんでした。 PCIコンプライアンスに関する多くの投稿を読みましたが、よくわからないいくつかの小さなことがあります。
正直なソフトウェア開発者のGoodGuyがいるとします。彼は主要なソフトウェアアーキテクチャを開発し、会社は彼を信頼し、合理的に必要なすべてのアクセス権を与えます。このソフトウェアは、定期的な支払い管理のためにクレジットカード番号を保存し、ソフトウェアはクレジットカードゲートウェイを使用して更新金額を請求します。
GoodGuy氏couldソフトウェアのセキュリティレベル（セキュリティで保護されたサーバーの場所の暗号化キー、ユーザーごとのキーなど）に関係なく、ユーザーのカードを解読するコードを記述します。ソフトウェア自体が何らかの形でカードデータを復号化できます。つまり、開発者は正直であるにもかかわらず、カードのデータにアクセスすることができました。
- 誰かがソフトウェアを使用してカードの詳細にアクセスするのを防ぐ、他の会社が実装した可能なソリューションは何ですか？
これは実際にはカードの詳細ではありません。それは、オンラインファイルストレージサービス、医療データなど、何でもかまいません。開発者は、自分が望むようにデータにアクセスできないようにすることができますが、ソフトウェアがそれらにアクセスできるようにすることができます（ユーザーの参加なしで）
PS：私はこんにちはGoodGuyです。悪いことをするつもりはありません。他の会社がこれにどう対処するのか不思議に思っています。彼らは開発者を信頼していますか？彼が辞任する場合でも、彼は彼と一緒に鍵ファイルを取ることができます。保存されているすべてのカードをフラッシュすることも、多くの既存の売上を減少させる可能性があるため、ここではオプションではありません。
PCI DSS セクション6、7、および8はすべてこの質問に関係しています。
たとえば、コードレビューが必要な6.3.2の一部：
コードの変更は、元のコードの作成者以外の個人、およびコードレビューの手法と安全なコーディング方法に精通している個人によってレビューされます。
6.4変更管理あり：
開発/テスト環境に割り当てられた担当者と本番環境に割り当てられた担当者の職務の分離。
7.1アクセスの制御...多くの環境では、コードを作成する開発者は、ライブデータで使用される運用システムにアクセスすることはありません。
システムコンポーネントとカード会員データへのアクセスを、そのようなアクセスを必要とする仕事をしている人だけに制限してください。
そして、8.7のタッチで、アクセス権を持つ人々を制限します。
データベースとアプリケーションの構成設定を調べて、すべてのユーザーアクセス、ユーザークエリ、およびユーザーアクション（移動、コピー、削除など）に対するデータベースの操作が、プログラムによる方法（たとえば、ストアドプロシージャ）のみであることを確認します。
さて、すべてが言ったように、信頼できるインサイダーはすべて完全に防御できますか？いいえ、「信頼できる」の定義そのものが原因です。これはすべての場所に当てはまります（「信頼された」スパイの数は？ジョンアンソニーウォーカーが思い浮かびます。）しかし、そのような脅威に対する防御、それらを軽減するためのベストプラクティス、およびPCI DSSこれらのプラクティスの数を要件として形式化します（クレジットカードの場合...他の秘密は自分で決めます！）
（そして、@ Stephen-Tousetが指摘するように、3.5.2は以下を必要とします：
カード会員データの暗号化/復号化に使用する秘密鍵と秘密鍵を、常に次の1つ（または複数）の形式で保存します。
そして、それらの方法の1つは次のとおりです。
安全な暗号化デバイス内（ホストセキュリティモジュール（HSM）またはPTS承認の対話式デバイスなど）
これには、日常のユーザーや管理者から実際のキーマテリアルをエスクローする利点があります。
それほど重要ではないが、これは（あなたが述べたように）信頼の問題であり、技術的な問題ではありません。私たちはできる限り注意を払い、立場を乱用しない信頼できる人を雇います。
とはいえ、不正なアクセスを制限したり、個人の信頼が適切に配置されていたり、実際に悪用されたりしていないことを確認するために実装できる制御がいくつかあります。
これらのコントロールの一部を次に示します。
- 秘密は秘密にしておく必要があります。鍵はソフトウェアに組み込む必要がありますしないでください。これらは、アプリケーションの開発者ではなく、アプリケーションインスタンスを管理または使用するユーザーによって生成および管理される必要があります。つまり、開発環境で使用されるキーはQA環境で使用されるキーとは異なり、実際には製品で使用されるキーとは異なります。開発者が本番環境にアクセスする理由はめったにありません。そこの鍵へのアクセス。
- 職務の分離。これは、最後のポイントの終わりから継続します。開発者はアプリケーションを開発し、ネットワークエンジニアはネットワークトラフィックとデバイスを管理し、サーバーエンジニアはサーバーを管理し、データベース管理者はデータを監視します。ほとんどの場合、クレジットカード情報などの実際の機密データを格納する本番サーバーやデータベースに開発者がアクセスするのは不合理です。
- 作業の検証。この場合、主にコードレビューについて話しています。繰り返しになりますが、ほとんどの場合、開発者が誰かが何を知っているかを知るコードを他の誰かがそれを見なくても本番環境にプッシュできるはずはありません。これは意図的ではない間違いをキャッチするために明示的に設計されており、ベストプラクティスと規則が守られていますが、意図的に悪意のある追加に気づき、レッドフラグが立てられるようにするという有益な副作用があります。
リストされる可能性のある他の無数のコントロールがありますが、これらはそれらのほとんどが分類される主要なカテゴリーの一部です。
これを防止するためのコストは莫大であり、そのため、資金のある巨大な開発グループ以外ではめったに行われません。上記のコードレビュー、セキュリティレビューなどの説明はすべて良いアイデアですが、実際には、レビュープロセスが行われている間、資産の使用を数か月遅らせるよりも、機能するコードを入手することに顧客の関心が高まっています。
私の会社が扱っている大多数のケースは、社内で使用するためにカスタムソフトウェアを作成するためにリソースを費やすことをいとわないが、顧客の連絡先追跡システムやプロジェクト管理のために、氷河期のISO適合開発委員会を利用していない中規模企業です。データベースを改善することができます。
実際に言えば、信頼できるソフトウェアベンダのみに対処する以外に、この種の悪用を防ぐ方法はほとんどありません。もちろんこれは解決策ではありませんが、少なくとも顧客の心を正しく設定し、ビジネスパートナーを注意深く選ぶように導くかもしれません-そしてソフトウェアベンダーisビジネスパートナー、最も優れたものの1つほとんどの場合、人々はこれに驚くほど盲目であるように見えますが、どんな会社でも親密になります。
Google、Apple、Microsoftなどで過去数年間に発生したスキャンダルと、NSAの関与。またはGoogleの自己主導のプライバシーの侵略です。開発者ありました誰かが顧客のデータを盗むことができること、およびこれらの特定の組織が十分に余裕のあるセキュリティレビュープロセスがキャッチできなかったことを確認します。これは本当に「Quis custodiet ipsos custodes？」問題（ 「誰が警備員を守っていますか？」）。
私自身のケースでは、お客様のデータを自分で保持することは絶対にないと判断しました。つまり、私たちは顧客サイトの近くで安価な小さなサーバーを立ち上げ、それらがビジネスに直接サービスを提供します。これは、めちゃくちゃ高速なインターネットと安価なハードウェアの時代です。中小企業は、世界中のどこからでもデータにアクセスするためにクラウドサービスを必要としません。安全性とデータの冗長性を確保するために、ネットワーク経由のバックアップを提供していますが、そのすべての暗号化されたblobは読み取りできないためです。
私たちはcould確かに彼らのサーバーに穴を開け、私たちが望むなら彼らの信頼を乱用します。しかし、誰かが悪をやめるのを止める方法はありません。私の会社の所有者として、セキュリティとVSの使いやすさの最適なバランス（私たちとクライアントにとって）にデータを保持させることを決めました。暗号化されたバックアップのみを保持します。
先ほど「クラウド」について触れました。これはおそらく、これまで誰もが想像したことのない、データセキュリティに対する最大の脅威の1つであり、顧客のデータが手に届かなくなった後の顧客データの保護を保証する方法はまったくありません。 「所有は法律の90％である」というのは良い教訓です。なぜなら、現代ではデータセキュリティの90％だからです。
1人の開発者が複数の帽子をかぶる中小企業（DBA、sysadmin、テクニカルサポート、ウェブマスターなど）の場合、PCI DSS要件を満たすというタスクは面倒です。機密データを取得する開発者はサードパーティAPIを使用し、機密データの処理と保存はtrustedで行われますあなた自身のウェブサイトの代わりに第三者のウェブサイト。
クレジットカード取引と定期的な支払い管理の場合、自分でロールする代わりに、PCI DSS準拠、であるPaypalを使用できますシステムです。もちろん、トランザクション中に顧客が実際にサードパーティのWebサイトにリダイレクトされるようにするには、コードを精査する必要があります。
結局のところ、あなたはあなたのために仕事をするために雇われている誰か（信頼できる開発者または信頼できる第三者）を信頼し始める必要があります。それ以外の場合は、すべて自分で行う必要があります。
多くの場合、開発者は顧客データベースに完全にアクセスできません。
私の会社では、すべての開発は匿名化されたデータベースで行われています-クレジットカード番号、個人情報などが削除され、混乱しています。ライブデータベースは顧客のマシン上にあり、中小規模の開発者はこれらのテーブルに対する読み取りアクセス権を持ちません。
システムパスワードを使用してそれらにアクセスできますが、そうするために、パスワードを抽出するためのファイルの取得と、「間違った」マシンからデータベースへのログインの両方がログに記録されます。
私が見た他のシステムには、クレジットカードの詳細の暗号化と、開発者が利用できないキーが含まれます。
結局のところ、十分に決定された開発者はほとんどすべてにアクセスできますが、偶然の誘惑を回避することを困難にすることで、ロギングすることで、反響があることを明確にします。
[〜＃〜] dukpt [〜＃〜] について誰も言及していないことに驚いていますが、それはおそらく、主要な支払いゲートウェイのいくつかがサポートに取り掛からなかったためであり、おそらく今はそうしないでしょう。 TripleDESはブルートフォース攻撃の対象になります。しかし、それは当時の素晴らしいアイデアであり、現代の暗号化でそれができないような理由はありません。一部のベンダーはまだDUKPTまたはそれに類するものを備えたカードリーダーを販売しており、暗号化をサポートし、より大きなもののプロキシとして機能するいくつかの小さなプロセッサがあります。
私はWikiの記事に何も追加できません。また、それがどのように機能するかを完全に理解しているとは主張していません。しかし、基本的に、ハードウェアは改ざんに強く、暗号化機能が組み込まれており、暗号化または編集された [〜＃〜] pan [〜＃〜] を発行します。それを解読できるのは支払いゲートウェイだけなので、ソフトウェアの販売者または開発者は悪意や過失によってそれを危険にさらすことはできません。
開発者がそのような秘密のデータにアクセスできないようにする方法を説明するすべての回答に加えて、主要な間接的な方法もあります。アクセスログです。
クエリは、シェルコマンドなどと同様にログに記録できます。これらのログは、個々の開発者が削除できないように保存する必要があります。このようにして、アクセス権がある場合でも、赤いフラグを立てることができます。理由彼らはすべてのクレジットカード番号が必要ですか？生産中？ -これの重要な部分は、開発者が作業に独自の資格情報を使用していること、および特定の人が自分の行動に責任を負うことにつながることのない「共有アカウント」がないことです。