セキュアOS塾-04に参加しました

シェアする

  • このエントリーをはてなブックマークに追加

セキュアOS塾-04に参加しました。 →セキュアOS塾-04 – SE-PostgreSQL vs Oracle Label Security

問題意識

セキュリティをアプリケーション任せにしてはいけない! だって大変だもの。アプリは複雑だしデカイし。。。 – OSでの実装→SE Linux, Trusted Solaris – RDBMSでの実装→SE-PostgreSQL, Oracle Label Security + Oracle Database Vault

SE-PostgreSQL

SE Linuxと連携する。 しくみもSE Linuxと似ている。 – SE Linux: システムコールをhookして強制アクセス制御をかける – SE-PostgreSQL: クエリ実行要求をhookして強制アクセス制御をかける 実際は・・・クエリ実行要求をPostgreSQL-SEモジュールがhookして、 SE Linuxにエスカレーションして判断してもらう。 SE Linuxのラベルを使って、行レベルアクセス制御を実現する。 DBMSのACLの後段で、特権ユーザに対しても制御をかけることができるのが特徴。 基本機能は充実している(Oracle Label Securityよりあるはず)。 でも、事例が少ない。 ※SE Linux以外とは(今のところ)連携できない ※ただし、PostgreSQL側のソースをきれいに修正して、強制アクセス制御呼び出しのエントリポイントを整備しようという流れはある。

Trusted Procedure

関数に対して特定のラベルを付与できる。 →一時的に権限を変更できる

行レベル制御と制約

FK制約により制約を受ける→ある程度の推測ができてしまう。 通称: 隠れチャネル 例: unique制約がある列に、使えるはずのデータを挿入しようとすると、unique制約違反が出ることがある

監査ログ

  • 誰が
  • 何に
  • 何をした かを記録する。 SE-PostgreSQLではログファイルに出力する。 将来的にはauditdとの統合を目論んでいる。

強み

セキュリティについて統合管理できる。 – すべてのレイヤーで一貫してSE Linuxのセキュリティポリシーを利用できる – 情報の形態ではなく、中身で制御できる – すべてのパスでチェックできる ★標準的なLAPPを、SE-LAPP(SE Linux + Apache SE Linux plus + PHP + SE-PostgreSQL)で強固にできる。

パフォーマンス

必要なもののみに絞り込むことが大事。 データ量(メモリに載るかどうか)にもよるが、経験上2~10%のオーバーヘッドがある。

Oracle Label Security

各行にセキュリティ情報(ラベル)を付加する。 DBMSが、下記のルールに応じて自動的にwhere句を追加してフィルタリングする。 →Oracle, IBMが特許を持っている方式らしい – レベル – 単純な優先度として使うことが多い – 区分 – 属性による制御に利用することが多い – グループ – 階層化が可能 – 部門など、階層化できるものに利用することが多い ラベル→Enterprise Managerで作れる – 読み取り: 権限が上位だと読み込める – 書き込み: 権限が上位でも書き込めない(漏洩防止) ※Label Securityだけでは強制アクセス制御は実現できない(=特権ユーザの制御ができない)。 強制アクセス制御はLabel SEcurity + Database Vaultで実現する。

Trusted Stored Procedure

Enterprise Managerで作れる

監査ログ

Oracleの普通のログと一緒。

強み

商用である。事例がある。 – 金融機関 – 親会社しか見られない情報・子会社が見られる情報などの制御を実現 – 医療機関 – 医師が、担当患者のカルテしか見られないように、などの制御を実現 認証を受けている。 →ISO/IEC15408でEAL4+ 他のOracle製品と統合している。 GUIで操作できるのもイイ。

パフォーマンス

細かい数値はナイショ。必要なものに絞り込むことが大事。

メモ

PostgreSQLではviewはセキュリティ目的では使えない。 例: だめなview→create view secret as select * from data where type = 'secret'; 理由: ユーザ定義関数をいじることでバイパスできてしまうため コストを指定してOptimizerを操作できる →Optimizerは軽い処理を優先する →ユーザ定義関数が先に実行される

ヒトコト

SE-PostgreSQLはSE Linuxとセットなのがよくもあり悪くもあり。 現時点ではマイナスポイントかなぁ。って感じ。 SE Linux→最初の導入ハードルが高い→使いたくない→使われない→ハードルが低くならない・・・ というループにハマっている感じ。もっていない。 あと、プレゼン自体の流れが特徴的でおもしろかった。 とてもセキュリティ界隈の人っぽい、というか、SE Linuxっぽい。 正確で厳密でわかりづらい。 でも楽しいです。

ads

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

ads