セキュア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っぽい。 正確で厳密でわかりづらい。 でも楽しいです。
See also
- #isucon チーム「ウー馬場ーイー222」でISUCON13本選に参加し30位になりました
- 「SRE≠インフラなんだけどもう誤解されちゃってるから、DevOps新実装としてSite Production Engineeringはいかがでしょう?」でJAWS DAYS 2022に登壇しました #jawsdays #jawsug
- #isucon チーム「シン・ウー馬場ーイー2」でISUCON12本選に進出し12位になりました
- #isucon チーム「シン・ウー馬場ーイー2」でISUCON12予選に参加し2位で予選突破しました
- 「非ITの事業会社にSREと言わずにSREを持ち込んだ」SRE NEXT 2022で登壇しました #srenext