IBM DB2データベース管理システムは、70年代から開発を開始し、現在、企業のDBMS市場で確固たる地位を占めており、パフォーマンス、信頼性、セキュリティ、およびスケーラビリティの高い要件を満たしています。 民間セクターでは、IBM DB2 Expressの無料バージョンが利用可能であるにもかかわらず、DB2システムは普及していません。 おそらくこれが原因で、DB2のセットアップと使用に関するインターネット上の記事はあまり多くありません。
DB2セキュリティモデルには広範な機能があり、DBMS自体を使用して、外部の影響からデータを保護し、内部ユーザーのアクセス権を区別することができます。
ただし、準備の整っていないユーザーがこの多様性をすべて一から理解することは難しいため、この記事ではいくつかの重要な側面について説明します。
エントリーポイント
DB2へのエントリポイントは次のとおりです。DBMS->インスタンス。特定のポートにバインドできます->特定のデータベースの名前。 セキュリティ設定は、特定のインスタンスと特定のデータベースの両方で変更できます。
認証
認証は、DB2サーバーに接続しようとするときに適用される主要なセキュリティメカニズムです。 認証は、提供された資格情報が正しいことを検証します。 DB2の主な機能は、ユーザー認証が外部プラグインによってのみ実行されることです。 OracleやMS SQL Serverとは異なり、内部ユーザーはここには存在しません。 IBM Data Studioプログラムにあるユーザー作成機能でさえ、実際にはユーザーを作成しませんが、指定したユーザーにデータベースに接続する特権を割り当てます。
いくつかの認証オプションがあります;望ましいオプションは、データベースマネージャーのAUTHENTICATIONパラメーターによって規制されます。 このパラメーターの値は、クライアント認証が実行される場所（サーバー側またはクライアント側）とデータが暗号化された形式で送信されるかどうか（_ENCRYPTで終わる値）に影響します。 このパラメーターでサポートされている値は、次の
アドレスで入手でき
ます。sysibmadm.dbmcfgテーブルへのクエリを使用して、データベースマネージャーの構成を表示できますが、このためには、すべてのデータベースにアクセスする必要がありますが、常にアクセスできるとは限りません。 サーバーへのローカルアクセスがある場合は、コマンドラインプロセッサ（Windowsではdb2またはdb2.exe）を開き、インスタンスに接続して次のコマンドを実行できます。
db2 => attach to db2inst1
db2 => get database manager configurationAUTHENTICATIONのデフォルト値はSERVERです。 提供されたユーザー資格情報の検証は、オペレーティングシステムを使用してサーバー側で実行されますが、すべてのデータは平文で送信され、攻撃者によって傍受される可能性があります。
Wiresharkで傍受された情報がどのように見えるかを見てみましょう。
EBCDICを表示すると、クライアントから送信されたログインとパスワードがパッケージに表示されます。
認証タイプをSERVER_ENCRYPTに変更すると、ログインとパスワードが暗号化された形式で送信され、サーバー側でチェックされます。
値は次のように変更されます。
db2 => attach to db2inst1
db2 => update database manager configuration using authentication server_encrypt
db2 => db2stop force
db2 => db2start認証パッケージは次のようになります。
ただし、クエリテキストと結果はクリアテキストで送信されます。
Wiresharkのリクエストパケット：
Wireshark応答パケット：
AUTHENTICATIONパラメーターがDATA_ENCRYPTに設定されている場合、ユーザー資格情報は暗号化され、クライアントとサーバー間で送信される情報も暗号化されます。
値は上記の例と同様に変化します。
db2 => attach to db2inst1
db2 => update database manager configuration using authentication data_encrypt
db2 => db2stop force
db2 => db2startその後、送信されるデータも暗号化されます。
また、クライアント認証タイプにも注意してください。 このタイプの認証では、クライアントとサーバーの間に安全な通信チャネルが存在すると考えられており、ユーザーがクライアントにアクセスできる場合、資格情報を確認せずにサーバーにアクセスできます。 つまり、認証はクライアント側で行われ、サーバー側の検証は実行されません。 サーバーに接続するユーザーがアクセス権を持っていなくても、PUBLICグループに割り当てられているすべての特権を取得します。 したがって、このタイプの認証は使用しないでください。これにより、攻撃者は多くの労力をかけずにサーバーにアクセスできるようになります。
突然何らかの理由でこのタイプの認証が必要になった場合、最終的にユーザー資格情報の検証方法に影響を与える2つの追加パラメーターがあることを考慮する必要があります。 これは
trust_allclntsパラメーターであり、これを使用して信頼できると見なされるクライアントを指定できます
。trust_clntauthパラメーターは、接続中に転送されたログインとパスワードを確認する場所を決定します。 これらのパラメーターは両方とも、AUTHENTICATIONパラメーターがCLIENTに設定されている場合にのみ認証に影響します。
認証が成功した場合、ユーザーIDはDB2 IDと一致します。 通常、識別子はユーザー名と一致しますが、大文字を使用します。
ログイン
承認プロセス中に、ユーザーが要求したアクションに必要な権限をユーザーが持っているかどうかがチェックされます。 DBMSインスタンスとデータベースの権限があります。
特定のインスタンスの権限レベルは、データベースマネージャーの構成で指定されます。 これらは次の機関です。
- SYSADM（システム管理者特権）
- SYSCTRL（システム管理機関）
- SYSMAINT（システムメンテナンス認証）
- SYSMON（システム監視機関）
これらの特権は、ユーザーが属するグループを指定することにより設定されます。 これを行うには、dbmcfgファイルの以下のパラメーターを使用します（上記の許可に従って）。
DB2ツールを使用してグループの一部であるユーザーのリストを取得するのは簡単です。オペレーティングシステム自体でこれを行うか、特定のユーザーが属するグループを分析する必要があります（クエリの「有用なクエリ」を参照）。
DB2をセットアップするときは、SYSADM権限が割り当てられているユーザーのリストを確認することが不可欠です。 この権限により、すべてのデータベースオブジェクトを管理できます。
特定のデータベースの資格情報は、
SYSCAT.DBAUTHビューで表示できます 。 ユーザーがデータベースにアクセスできるかどうかを決定するCONNECTAUTH特権と、フェンスされていないプロシージャおよび関数の作成を担当するNOFENCEAUTH特権に注意する必要があります。 このような手順は、データベースのアドレス空間で実行され、エラーが発生した場合、データベースとその中のテーブルの整合性に違反する可能性があります。
特典
DB2の特権は、さまざまなオブジェクトに付与できます。 テーブルのアクセス権限は、
SYSCAT.TABAUTHビューで表示できます。 付与された特権のタイプに関するデータは、特権自体（SELECTAUTH、DELETEAUTHなど）に応じて個別の列に格納されます。 REFERENCESおよびUPDATE特権に対してGRANTコマンドを使用して特権を付与する場合、これらの特権が適用される列の名前も指定できます。 これに関する情報は、
SYSCAT.COLAUTHビューで見つけることができます
。ルーチン（関数、プロシージャー、およびメソッド）の特権は、
SYSCAT.ROUTINEAUTHビューで表示できます 。 SPECIFICNAMEフィールドとTYPENAMEフィールドに応じて、ここにあるものはすべて些細なことではなく、特定のスキームのすべてのルーチンに特権を付与できます。
ユーザー、グループ、役割
すべてのデータベース許可とさまざまな特権をユーザー、グループ、またはロールに付与できます。 ユーザー、グループ、およびグループ内のユーザーメンバーシップの存在は、データベース自体の外部で規制されています。 この点で、権限と特権を発行する際には、特定の推奨事項を考慮し、いくつかの微妙な点を知っておくことをお勧めします。 データベースに特権と権限、特にデータベースに接続する機能（CONNECTAUTH）をグループに付与することはお勧めしません。 特権は、それを必要とする特定のユーザーまたはロールに付与する必要があります。 ロールサポートは、バージョン9.5以降、DB2で導入されました。 ロールメンバシップ管理は、データベース自体の内部で実行されます。
また、DB2には組み込みのPUBLICロールがあります。 データベースユーザーはPUBLICロールを提供する必要はありません。PUBLICロールをユーザーから撤回することはできません。 PUBLICロールに特権が付与されると、実際にはすべてのデータベースユーザーに特権が付与されます。 PUBLICロールのデータベース権限は付与しないでください。 テーブルおよびビューに対する特権は、表示のみを目的として、再割り当ての可能性なしに、細心の注意を払って発行する必要があります（グラントオプション付き）。
認証の性質上、システム内のユーザーまたはグループの存在について特権はチェックされません。 その結果、システムの実際のユーザーに縛られることなく、認証ユーザーがシステムに表示される場合があります。 次のSQLクエリを使用して、これらのユーザーを見つけることができます。
SELECT authid FROM sysibmadm.authorizationids WHERE authidtype = 'U' AND authid NOT IN (SELECT username FROM TABLE(sysfun.USERS()) AS W)
このようなグループの検索には同様のクエリが使用されますが、クエリはPUBLICデータを表示する必要がないことを示しています。
SELECT authid FROM sysibmadm.authorizationids WHERE authidtype = 'G' AND authid NOT IN (SELECT groupname FROM TABLE(sysfun.groups()) AS W) AND authid != 'PUBLIC'Lbac
DB2には、テーブル内のデータにアクセスするための強力なラベルベースのアクセス制御があります。 このメカニズムにより、特定の行または列にセキュリティラベルを設定して、保護されたデータにアクセスできないユーザーがその存在に気付かないようにすることができます。 製造元にはこのトピックに関するトレーニングマニュアルがあるため、LBACの実装方法について詳しく説明することは意味がありません。
www.ibm.com/developerworks/ru/edu/dm0605wong/index.html自動スキャンツール
IBM DB2サーバーのセキュリティを設定する際の重要なポイントは、セキュリティスキャナー（たとえば、DB2、MaxPatrolなどのNGS SQuirreL）の使用です。 スキャナーは、見落とした設定の脆弱性を明示的に示すか、分析に便利な形式で情報を表示します。
NGS SQuirreL for DB2：
MaxPatrol：
便利なクエリとコマンド
データベースマネージャーの設定を取得します。
select name, value from sysibmadm.dbmcfgどちらか
db2 => get dbm cfgデータベースマネージャーの設定を変更します。
db2 => update database manager configuration using
:
db2 => db2stop force
db2 => db2start
:
select name, value from sysibmadm.dbcfg
db2 => get db cfg for
:
select username from table(sysfun.USERS()) AS t
:
select groupname from table(sysfun.GROUPS()) AS t
(, , ):
select AUTHID, AUTHIDTYPE from sysibmadm.AUTHORIZATIONIDS
:
select current server from sysibm.sysdummy1
:
select user from sysibm.sysdummy1
, :
select GROUPNAME from table(sysfun.groups_for_user('<username>')) as t
:
$ db2ls
:
$ db2ilist
:
select * from tabname fetch first 5 rows only