アプリケーションがsaアカウントを使用しない理由

私の最初の質問は、穏やかにしてください。saアカウントは、SQL Serverおよびすべてのデータベース、ユーザー、アクセス許可などを完全に制御できることを理解しています。

完璧な、ビジネスマンに焦点を当てた理由がない限り、アプリケーションはsaパスワードを使用すべきではないという絶対的な信念を持っています。この質問への回答には、ITに焦点を当てた議論の多くの理由が含まれています

saパスワードを使用しないと機能しない新しいサービス管理システムの受け入れを余儀なくされています。評価を設定するときにサーバーチームがそれをインストールして、db_createrと必要だと思った他のアクセス許可を組み込んで設定した固定ロールを使用しようと試みた理由を解決する時間はありませんでした。失敗しました。次に、サーバーチームにsaアカウントを使用してインストールさせますが、そのデータベースのdboロールのアカウントで実行しましたが、それも失敗しました。不機嫌なことに、私はsysadminロールのアカウントで実行しようとしましたが、それでも失敗し、利用可能な時間よりも多くの時間を費やすことなく何が起こっているのかを理解できる有用なエラーメッセージがありませんでした。構成ファイルにクリアテキストで保存されたsaアカウントとパスワードでのみ機能します。

これを問い合わせると、サーバーチームがベンダーと話し合ったところ、「問題は何ですか？」そして、「パスワードのスクランブルを見ることができます」スクランブルffs

私はファイルへのアクセスを制限する方法と手段があることを知っていますが、それは私の意見ではセキュリティの別の弱点です

とにかく、私の質問は、誰かが私がビジネスにこれが悪いことであり、大きなノーノーである理由を説明するために使用できるいくつかのドキュメントを私に指すことができますか？私は、セキュリティを真剣に考える必要があるという分野で働いており、ビジネスを理解するのに苦労しており、最終的にはいずれにしても上位にランクされる可能性がありますが、試してみる必要があります。

それはあなたのビジネスに依存しますが、ほとんどの場合の主なことは、それがITの問題と見なされないようにすることです。これはセキュリティの問題であり、2つの重なっているビジネスの人々は、単に「一般的なITのことを言っている」よりも「セキュリティ」と言う方が耳を傾ける可能性が高くなります。

セキュリティ要件があるクライアントと連携していますか？それは始めるのに良い場所です。saレベルのアクセスでアプリを実行した場合、または特権アクセスを使用していなくても資格情報を適切に保護しなかったアプリのみを実行した場合（可能な場合、保存されたユーザー/パスよりもWindows統合を強くお勧めします）、セキュリティの対象となりました監査、その監査は失敗し、顧客を失うリスク、および/またはグループのクライアント（私が主に取り組んでいる製品の場合は銀行組織、グループの他の部分は警察と健康を扱う当局など）セキュリティは、目的に合ったサービスの一部です。ビジネスの人々は、ITの推奨事項に通常口先だけで支払っても、その潜在的な脅威の重大度を理解します。

クライアントが課す要件を無視しても、さまざまな業界標準のセキュリティ標準を満たすように努力すると、この種のアプリケーション認証は、一般的に考えられているベストプラクティスからは程遠いため、監査に直面して失敗します「単にすべきではない」リストに載っています。セキュリティがアプリケーションの重要な部分であることをビジネスの意思決定者に明確にし、このベンダーが気付いていない（または少なくとも適切に懸念している）ことにより、他に何ができないかについて疑問を抱きます。対処：DBセキュリティのベストプラクティスについて知ることは（まあ、そうあるべきです）彼らの仕事の一部であり、それを実装することは難しくありません。

また、あなた（購入者）は、ベンダーに合理的なセキュリティ要件を指示するべきであり、その逆ではないことを指摘します。それはあなたのデータなので、十分に安全であると考えられるものを述べる資格がありません。

SAアクセスを必要とするアプリケーションはありません。（その唯一の目的が何らかのデータベース管理である場合を除きます。）

一般に、ビジネスがログインに必要とする以上の権限（アプリケーションまたは個人）をログインに許可しないことは原則です。

完全に安全なアプリケーションはありません。ほとんどには、何らかのSQLインジェクションまたはXSSの脆弱性があります。侵入者が自分の選択したステートメントを実行し、「SA」アクセス権を持っている場合、データを瞬時に破壊する可能性のある多くのことがあります。（特に、データが法執行機関によって使用されるため、データを信頼する必要がある場合。）誰かが単一のレコードでさえ意図的に変更することができ、その情報が漏洩した場合、ステークホルダーに何をする必要があるか尋ねます。

現在、「SA」アクセスを使用すると、アプリケーションのデータベースだけでなく、システム上の他のすべてのデータベースも変更できます。そのため、すべてのデータベースのコピーを作成して新聞に送信する場合、関係者に何をするか尋ねてください。不満を抱く従業員がこのセキュリティホールの存在を理解した場合に、それが起こる可能性があるためです。

ベンダーは、パスワードをスクランブルできると言った。それがBSです。パスワードを使用するには、アプリケーションがパスワードにクリアテキストでアクセスする必要があるため、パスワードの暗号化を解除するためのキーはスクランブルされずにすぐ隣に保存されます。また、前述のように、本当の問題は誰かがこのパスワードを見つけることではありません。脆弱性を介してこのシステムを使用する（誤）人は、パスワードを見ることなく、すべてのデータベースに完全にアクセスできます。

SAが必要とされる最も可能性の高い原因は、アプリケーションがSQLエージェントと対話する必要があることです。少なくとも、それは正しく実装するのが難しい機能の1つであり、ほとんどの人は「use SA」ルートを使用してそれを回避します。「SA」自体が必要なのは、ベンダーがシステム管理者権限を確認する方法を知らないためです。

あなたが試すことができる2つの解決策があります：

1. SA（とにかくセキュリティのベストプラクティス）の名前を変更し、制限された権限を持つ「SA」という新しいアカウントを作成します。（これを試したことはありませんが、動作するはずです）

2. ソフトウェアをインストールしないでください。プロとしてのあなたはその行動の責任を負うことができないので、それをインストールすべきではありません。比較するために、配管工にパイプラインやお金を節約するために、暖炉の周りではなく直接暖炉にガスラインを通すように依頼してください。あなたはこの画像を笑っているかもしれませんが、それは適切な比較だと思います-このソフトウェアは遅かれ早かれ、おそらく早く爆発します。そして、それはビジネスをダウンさせるかもしれません。

これらすべてがこのソフトウェアを必要とする「それら」を止めない場合、私があなたに与えることができる最後の推奨事項は実行することです。データに何かが発生した場合、最初に責任を負うことになります。したがって、このアプリケーションを使用すると、おそらく職務上のセキュリティがないので、少なくともいくつかの雇用主を見つける雇用主を見つけてください。

これを攻撃する2つの行が表示されます。

• コンプライアンス。ショップで有効なコンプライアンス基準はありますか？その文言を注意深く検索し、アプリケーションの「要件」と互換性のないものを見つけるかどうかを確認します。saアプリケーションによる使用を妨げるものを見つけた場合、アプリケーションがビジネスの責任を負わせるなど、防弾防水ケースがあります。

• ユーザー管理者アクセス。sa有効なアクセスを必要とするアプリケーションsaが、アプリケーションがインストールされているワークステーションの管理者権限を持つすべての企業ユーザーにアクセスを許可する場合を明確に提示してください。saアプリケーションを実行するローカル管理者からパスワードを隠す方法はありません。これは事実であり、「スクランブル」の量がこれを防ぐことはできません。ローカル管理者が必要に応じてアクセスできないローカルの信頼のルートはありません。必要なアプリケーションがあるということは、そのアプリケーションを実行しているすべてのユーザーに特権をsa与えることに等しいことを明確にしてくださいsa。それが何を意味するのか、ユーザーが効果的に何ができるのかを説明してください：

  • 読む能力任意のこのアプリケーションからではなく、そのサーバー上でホストされている他のデータベースからだけではなく、サーバーにデータを
  • 変更する機能任意の同じサーバ上の他のデータベースから再び、サーバー上のデータを
  • 変更が行われた後、彼の行動の痕跡を消去する機能
  • 特定のアクションが別のユーザーによって行われたように見せるために、監査と履歴を変更する機能
  • SQL Serverの資格情報を使用して、このサーバーを信頼する他のリソースに対する攻撃をエスカレートする機能。これは、SQL Serverが単なる踏み台として使用できるため、ファイル共有、Exchangeサーバーなどを含むがこれらに限定されない、他のSQL Serverだけでなく他のリソースも意味します。

このアプリケーションを受け入れることは、アプリケーションを実行するワークステーションへの管理者アクセスを持つすべての従業員に上記のすべての権限を委任することを意味することを意思決定者に明確にしてください。ベンダーはsa、アプリケーションのパスワードを何らかの方法で「暗号化」することにより、その立場を守ろうとします。これは水を保持しません。管理者からの攻撃に耐えられる暗号化スキームはありません。また、ローカルで「隠された」パスワードを見つけるために必要な技術的スキルの量は完全に無関係であることを明確にします。従業員は自分でそれを行うつもりはなく、そのうちの1人がそれをグーグルで検索し、それを行う使いやすいスクリプトを発見します。

まず、saパスワードにはプレーンテキストが保存されていますか？財布で投票する必要があります。それが容認できると思う人は誰でも廃業する必要があります。

問題の説明に役立つ可能性のあるアナロジーを次に示します。従業員アリスは1階にアクセスする必要があります。彼女に建物全体のマスターキーを渡すのですか、それとも1階のキーだけにするのですか？回答：あなたは彼女に1階の鍵だけを渡します。どうして？偶発的または意図的な損傷の可能性を減らすためです。アリスがそもそも2階のサーバールームにアクセスできない場合、アリスは決して悪いことをしません。

それは最小の原則の原則です。

アプリケーションがsaアカウントを使用する必要がある理由については、PerfMonまたはExtended Eventsが回答できるはずの質問です。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アカウントの資格情報は、アプリケーションまたはインストーラログのどこにも保存されません。このソフトウェアは、インストール中に事前に作成されたデータベースを使用するオプションも提供します。

したがって、このITサービス管理ソフトウェアのインストールまたは操作にSAアカウントが必要かどうかを確認するだけです。

インストールの場合：一時的な「sa」アカウントを作成し、インストールを実行して、アカウントを削除します。

操作の場合：ペストのようなそのソフトウェアを避けてください。（または、その1つのデータベースのみを収容するスタンドアロンSQLサーバーをセットアップします。）

指定されたデフォルトのSQL Serverシステムセキュリティパラメータはすべて変更する必要があります。認証に混合モード（Windows認証とSQL Server認証の両方を有効にする）を使用しないことをお勧めします。代わりに、Windows認証のみに切り替えます。これにより、Windowsパスワードポリシーが適用され、パスワードの長さ、有効期間、および履歴が確認されます。SQL Server認証とは異なるWindowsパスワードポリシーの機能は、ログインロックアウトです。連続して何度もログオンに失敗すると、ログインがロックされ、使用できなくなります。

一方、SQL Server認証はブルートフォース攻撃の試行を検出する方法を提供しません。さらに悪いことに、SQL Serverは多数の高速ログイン試行を処理するように最適化されています。そのため、特定のSQL ServerシステムでSQL Server認証が必須の場合は、SAログインを無効にすることを強くお勧めします