2017-01-27 3 views
1

具体的には、WebアプリケーションでPHPとデータを扱っています。別のデータベースにユーザーデータを格納する際に追加のセキュリティはありますか?

私の知る限り、ユーザーデータにアクセスするための主な理由は以下のとおりです。商品発送などの通信のために

  • にログインするための

    それは私には思われますハッカーに最も関心のあるデータの種類はユーザーデータなので、特別な保護が必要です。

    これは可能な手法です。私は通常、データベース作業のためにPDOを使用します。したがって、サポートされているデータベースには以下が適用されます。

    • データベースを作成するには、単一のユーザーテーブルを使用してusersを作成します。
    • データベースに制限されたユーザーを作成しそれに応じて
    • メインログインスクリプトからPDOオブジェクトを作成し、ユーザーを認証含まれているスクリプトを呼び出します。
      • セキュリティを強化するため、このスクリプトはWebルートの外にある可能性がありますか?
    • セッション変数を使用して通常の処理を行います。特に関連する検索されたユーザ情報を格納する。
    • 私は、すべてのホストされたサーバがWebルートの外に何かを保存することが簡単に考えていない主なデータベース

    からのデータの残りの部分と先に行きます。

    ユーザデータベースが最も頻繁にアクセスされるデータの一部でない場合、ユーザデータベースが侵害される可能性は低いということです。

    また、ユーザーデータとパスワードを別々のテーブルに分けることも良い考えですが、別の質問に入れておきます。

    私はそれが完璧な解決策ではないことを示唆していませんが、私はをより良く探しています。保護。問題は、このような手法では、メインデータベースにユーザーの詳細を保存するよりもセキュリティが強化されますか?

  • +2

    データが侵害される可能性のある方法が多すぎます。 SQLインジェクションが不可能な場合は、データベースが追加でサイロ化されていないと、本質的に別のデータベースに保持することは本質的には安全です。ただし、データベースセキュリティは常に適用するのが良いことです。これは同じデータベース内にある可能性があります。 – user2864740

    +1

    @ user2864740のコメントに追加するには、特定のデータベースのみを許可する複数のdbユーザーアカウントを持つことができます.1はユーザーのログイン情報です。 – Xorifelse

    答えて

    1

    認証サービス&を完全に書くことができます。 OAuthを見てください。このサービスへのユーザー名とパスワードで認証すると、認証サーバーはサービスへのアクセスを可能にするトークンを生成することができます。

    https://en.wikipedia.org/wiki/OAuth

    +0

    私はこの隔離の大ファンです(必ずしもOAuthではなく、AA/Aのための隔離されたサービスです)。しかし、あまりにも一般的ではありません。 – user2864740

    +0

    私たちは、すべての異なるサービスにわたる認可のために、別々のサービスを提供しています。しかし、それは間違いなく多くの仕事です。私は個人的には、あなたのケースでは別のデータベースを必要としません。パスワードをうまくハッシュしてください。別のユーザーを使用してユーザー表にアクセスすることもできます。他のすべてのユーザーのテーブルへのアクセスを削除します。 –

    0

    はい、実際にそれは悪いアイデアではありませんが、私は違っこれを行うだろう:

    • は、データベース、ユーザーアカウント、それにし、必要なユーザデータテーブルを作成します。
    • ローカルホストであっても別のウェブホスト(例:userapi.myhost)を作成します。新しいウェブホストは、メインアプリケーションとは全く別の場所に独自のWebルートを持っているはずです。
    • は、スクリプトを使用して取得するためのAPI /変更ユーザーデータを作成(またはフレームワークを使用して)新しいホストに。
    • 認証は、あなたのAPIへのHTTP要求を保護し、特定のIP(APIが同じサーバー上にある場合でも、あなたのローカルIP)へのアクセスを制限します。
    • メインアプリは新しいAPIを使用してユーザーデータにアクセス/変更します。

    たとえば、ユーザーがメインパスワードを使用してメインアプリにログインしようとすると、メインアプリはログイン情報をapiに送信します。>正しい場合は情報を取得します。

    あなたの主なアプリがあなたのデータベースに異なるクエリの多くを行うと、おそらくそれらのいくつかは、セキュリティホールを持っているライブラリやサービスの多くを持つことができるので、これは、SQLインジェクションに対して保護することができます。 私は次のように提案します:

    • ユーザAPIをシンプルにしてテストしてください。
    • 二アプリ(さらにパスワード保護し、あなたのIPアドレスへのそれへのアクセスを制限する)上でのユーザ管理をしてください。

    残念ながら、これは完全にあなたを確保しません。ハッカーが自分のスクリプトを配置したり、コードを変更したり、ログインの詳細を見たり、メインアプリからユーザーデータにアクセスしたりするケースがあります。さて、他にもたくさんの方法があり、さまざまなソリューションがあります。 (Apacheのopenbase_dirの制限、コードへの "apache"ユーザの書き込み権限の削除、 "apache"ユーザからの書き込みハンドラの削除など)

    より良い保護を求めているので、もう少し多くの仕事や時間を投資する気にならないなら、それをお勧めします。

    関連する問題