アプリケーションがsaアカウントを使用しない理由
私の最初の質問は、穏やかにしてください。 saアカウントにより、SQL Serverおよびすべてのデータベース、ユーザー、権限などを完全に制御できることを理解しています。
私は、完璧な、ビジネスパーソンに焦点を当てた理由がなければ、アプリケーションがsaパスワードを使用してはならないという絶対的な確信があります。への回答 この質問 ITに焦点を当てた議論に対する私の推論の多くを含める
Saパスワードを使用しないと機能しない新しいサービス管理システムを受け入れることを余儀なくされています。評価を設定するときに理由を理解する時間はありませんでしたが、サーバーチームは、db_createrおよび必要だと思われるその他のアクセス許可を組み込んで設定した固定ロールを使用してそれをインストールしようとしました。失敗した。次に、サーバーチームにsaアカウントを使用してインストールさせましたが、データベースのdboロールのアカウントで実行しましたが、これも失敗しました。不機嫌にsysadminロールのアカウントで実行しようとしましたが、それでも失敗し、有用なエラーメッセージが表示されなかったため、利用可能な時間よりも多くの時間を費やすことなく、何が起こっているのかを理解できました。これは、構成ファイルにクリアテキストで保存されているsaアカウントとパスワードでのみ機能します。
私がこれを照会し、サーバーチームがベンダーと話したとき、彼らは「それの何が問題なのですか？」という心配な答えを得ました。その後、「パスワードのスクランブルを確認できます」スクランブルffs
私はファイルへのアクセスを制限する方法と手段があることを知っていますが、それは私の意見ではセキュリティのもう一つの弱点です
とにかく、私の質問は、これが悪いことであり、大きな問題ではない理由をビジネスに説明するために使用できるドキュメントを誰かが私に指摘することができるかどうかです。私はセキュリティに真剣に取り組む必要があり、ビジネスを理解するのに苦労していて、結局はランク外になるかもしれないということを意味する分野で働いていますが、私は試す必要があります。
それはあなたのビジネスに依存しますが、ほとんどの場合の主なことは、それがnotであることを確認することですITの問題と見なされます。これはセキュリティの問題であり、2つの重複するビジネスピープルは、「一般的なITについてうめき声を上げる」よりも「セキュリティ」と言う方が耳を傾ける可能性が高くなります。
セキュリティ要件のあるクライアントと協力していますか？それは開始するのに良い場所です。 saレベルのアクセスでアプリを実行した場合、または特権アクセスを使用していなくても資格情報を適切に保護しなかったアプリのみ（可能な場合は、保存されたユーザー/パスよりもWindows統合を強く推奨します）で、セキュリティの影響を受けた場合監査、その監査は失敗し、私たちは顧客を失うこと、および/または私たちのグループのクライアント（私が主に取り組んでいる製品の場合、銀行組織、グループの他の部分は警察と健康に対処する場合、銀行組織に返金する必要がある）のリスクを負うことになります当局など）セキュリティは、目的に適した製品の一部です。ビジネスの人々意志通常、ITの推奨事項にリップサービス以上のものを払わない場合でも、その潜在的な脅威の重大度を理解します。
クライアントが課した要件を無視しても、さまざまな業界標準のセキュリティ標準を満たすように努める場合、この種のアプリケーション認証は、一般的に考えられているベストプラクティスとはかけ離れているため、監査に直面して失敗します。 「単にやるべきではない」リストに載っています。セキュリティがアプリケーションの重要な部分であること、およびこのベンダーが気付いていない（または少なくとも適切に懸念している）ように見えないという事実は、他に何ができないのか疑問を抱かせるということをビジネスの意思決定者に明らかにします対処：DBセキュリティのベストプラクティスについて知ることは彼らの仕事の一部であり（そうでなければなりません）、それを実現することは難しくありません。
また、あなた（購入者）は、ベンダーに合理的なセキュリティ要件を指示する必要があり、その逆ではないことを指摘します。それはあなたのデータなので、彼らは十分に安全であると考えられるものを述べる資格がありません。
アプリケーションにSA=アクセスする必要はありません-（その唯一の目的が何らかのデータベース管理である場合を除いて）。
ビジネスで必要とされる以上の権限（アプリケーションまたは個人）をログインに付与することは、原則として禁止されています。
完全に安全なアプリケーションはありません。ほとんどには、SQLインジェクションまたはXSSの脆弱性があります。侵入者が自分の選択したステートメントを実行し、「SA」アクセス権を持っている場合、ビジネスに即座に影響を与える可能性のある多くのことがデータに起こります。 （特に、法執行機関で使用されているためデータを信頼する必要がある場合。）誰かが1つのレコードでも意図的に変更でき、その情報が漏えいしていないかどうか、関係者に何をすべきか尋ねます。
ここで、「SA」アクセスを使用すると、アプリケーションのデータベースだけでなく、システム上の他のすべてのデータベースも変更できます。したがって、すべてのデータベースのコピーを作成し、それを新聞に送信する場合、関係者に何をするか尋ねてください。不満を持った従業員がこのセキュリティホールの存在を発見した場合に、それが発生する可能性があるためです。
ベンダーは、パスワードをスクランブルすることができると言いました。それがBSです。アプリケーションはそれを使用するためにパスワードにクリアテキストでアクセスする必要があるので、パスワードを解読するためのキーはそのすぐ隣に解読されずに保存されます。また、前述のように、本当の問題はこのパスワードを見つけた人ではありません。これは、脆弱性を介してこのシステムを（誤）使用している人が、パスワードを見ることなくすべてのデータベースにフルアクセスできることです。
SAが必要とされる最も可能性の高い原因は、アプリケーションがSQLエージェントとやり取りする必要があることです。少なくとも、これは正しく実装するのが難しい関数の1つであり、ほとんどの人は "use SA"を使用します「SA」自体が必要なのは、ベンダーがsysadmin権限を確認する方法を知らないためかもしれません。
試すことができる2つのソリューションがあります。
名前をSA（とにかくセキュリティのベストプラクティス）に変更し、権限が制限された「SA」という新しいアカウントを作成します（これを試したことはありませんが、機能するはずです）。
ソフトウェアをインストールしないでください。プロとしてのあなたはその行動の責任を負うことができないので、あなたはそれをインストールすべきではありません。比較を行うために、配管工にガス管を暖炉の周りではなく直接通して、パイプやお金を節約するよう依頼してください。あなたはこの画像を笑っているかもしれませんが、私はそれが適切な比較であると信じています-このソフトウェアは遅かれ早かれ、おそらく早く爆発します。そして、そうなるとビジネスもダウンするかもしれません。
これらすべてが「彼ら」がこのソフトウェアを必要とすることを止めない場合、私があなたに与えることができる最後の推奨は実行することです。データに何かが起こった場合、あなたが最初に責任を負うことになります。したがって、このアプリケーションを使用すると、おそらく仕事の保障がないので、少なくともいくらかを与える雇用主を見つけてください。
これを攻撃する2つの行が表示されます。
コンプライアンス。ショップで有効な必須のコンプライアンス基準はありますか？その文言を注意深く検索し、アプリケーションの「要件」と互換性のないものを見つけていないか確認してください。アプリケーションによる
saの使用を妨げる何かを見つけた場合、アプリケーションがビジネスに責任を負わせるなどの防弾防水ケースがあります。ユーザー管理アクセス。実際に
saアクセスを必要とするアプリケーションが、アプリケーションがインストールされているワークステーションで管理者権限を持つすべての企業ユーザーにsaアクセスを与えるケースを明確に提示してください。アプリケーションが実行されるローカル管理者からsaパスワードを隠す方法はありません。つまりfactであり、「スクランブル」によってこれを防ぐことはできません。ローカルの管理者が望む場合、ローカルの信頼のルートはありません。saを必要とするアプリケーションを持つことは、アプリケーションを実行するすべてのユーザーにsa特権を与えることと同じであることを明確にしてください。それが何を意味するか、ユーザーが効果的に何ができるかを説明してください：- このアプリケーションだけでなく、そのサーバーでホストされている他のデータベースからでも、サーバーのanyデータを読み取る機能
- 同じサーバー上の他のデータベースから、サーバー上のanyデータを変更する機能
- 変更が行われた後、彼の行動の痕跡を消去する機能
- 監査と履歴を変更して、特定のアクションが別のユーザーによって実行されたように見せかける機能
- sQL Server資格情報を使用して、このサーバーを信頼するその他リソースへの攻撃をエスカレートする機能SQL Serverは踏み台としてのみ使用できるため、これは他のSQL Serverだけでなく、他のリソース（ファイル共有、Exchangeサーバーなど）も含む可能性があります。
このアプリケーションを受け入れることは、上記のすべての特権を委任するアプリケーションを実行しているワークステーションへの管理者アクセス権を持つすべての従業員を委託することを意思決定者に明確に伝えます。ベンダーは、アプリケーションのsaパスワードを「暗号化」するなど、何らかの方法でその立場を守ろうとします。これは水を保持しません。管理者からの攻撃に耐えられる暗号化スキームはありません。また、ローカルで「隠された」パスワードを見つけるために必要な技術的なスキルの量は完全に無関係であることを明確にします。従業員は自分でそれを行うつもりはありません。彼らの1人がそれをググって、それを行う使いやすいスクリプトを見つけます。
まず、saパスワードはプレーンテキストで保存されていますか？あなたはあなたの財布で投票する必要があります。それを容認できると考える人は、廃業する必要があります。
問題を説明するのに役立つかもしれないanologyはここにあります：従業員アリスは1階へのアクセスを必要とします。建物全体のマスターキー、または1階のキーだけを彼女に渡しますか？回答：あなたは彼女に1階の鍵だけを渡します。どうして？偶発的または意図的な損傷の可能性を減らすためです。アリスがそもそも2階のサーバールームにたどり着けない場合、アリスはそこで何も悪いことはしません。
それは最小特権の原則です。
アプリケーションがsaアカウントを使用する必要がある理由については、PerfMonまたは拡張イベントで回答できるようにする必要があります。 T-SQLテンプレートを使用してPerfMonトレースを作成します。アプリケーション名でフィルタリングされる場合があります。
ここで、saの使用に対するもう1つの論点を挙げます。saアカウントを使用するには、SQL Serverサービスが混合認証モードである必要があります。 Kerberosのすべての安全な機能を活用できるため、Windowsのみの認証の方が適しています。
技術的な観点からは、アプリケーションにSA権限が必要になる理由はありません。おそらくアプリケーションの開発者がログインにsysadmin権限があるかどうかを確認し、そうでない場合は単にそうするだけです。このようにして、アプリケーションにSA権限が必要であると主張できます。
このアプリケーションが必要な場合は、他に何もない別のインスタンスで実行します。
ベンダーがアプリケーションのどこかでXP_CMDSHELLを使用しているため、「sa」を要求/要求している可能性があります。 （XP_CMDSHELLへの無制限のアクセスで起こりうる損害について始めないでください。これにより、データだけでなく、ホストマシン、およびおそらくネットワーク上の他のあらゆるものが管理者のようなアクセスに開かれる可能性があると言って十分に言えます）
正当な必要がある場合は、プロキシアカウントを介してアクセスを制限することができます。たとえば、BOLを参照してください： http://msdn.Microsoft.com/en-us/library/ms175046.aspx
アプリケーションが動作するためにSAアカウントとパスワードを必要とするべきではありません。
ただし、私はITサービス管理製品をインストールしました。インストールプロセス中に、SAアカウント資格情報を指定して、インストーラーがDBを作成し、DBにアカウントをアタッチできるようにするオプションがあります。 SAアカウントの資格情報は、アプリケーションまたはインストーラーのログのどこにも保存されません。このソフトウェアは、インストール中に事前に作成されたデータベースを使用するオプションも提供します。
したがって、SAアカウントがインストールまたはこのITサービス管理ソフトウェアの操作に必要かどうかを確認します。
インストールの場合：一時的な「sa」アカウントを作成し、インストールを実行して、アカウントを削除します。
操作の場合：ペストのようなソフトウェアは避けてください。 （または、その1つのデータベースのみを格納するスタンドアロンSQLサーバーをセットアップします。）
提供されているデフォルトのSQL Serverシステムセキュリティパラメータを変更する必要があります。認証に混合モード（WindowsとSQL Serverの両方の認証を有効にする）を使用しないことをお勧めします。代わりに、Windows認証のみに切り替えます。これにより、Windowsパスワードポリシーが適用され、パスワードの長さ、有効期間、および履歴がチェックされます。 SQL Server認証とは異なるWindowsパスワードポリシーの機能は、ログインのロックアウトです。ログインに何度も失敗すると、ログインがロックされ、以降の使用に使用できなくなります。
一方、SQL Server認証はブルートフォース攻撃の試みを検出する方法を提供していません。さらに悪いことに、SQL Serverは多数の高速ログイン試行を処理するように最適化されています。そのため、SQL Server認証が特定のSQL Serverシステムで必須である場合、SAログインを無効にすることを強くお勧めします