OSS-DB Goldのサンプル問題（本番形式・解説付き）

OSS-DB Gold（LPI-Japan・OSS-DB Exam Gold（Ver.3.0・PostgreSQL））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（30問）の冒頭から抜粋したオリジナル問題です。当サイトは全300問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

あるサーバで postgresql.conf に ssl = on を設定し、証明書と秘密鍵を配置して PostgreSQL を再起動した。この時点の状態の説明として適切なものはどれか。

クライアントが sslmode に何を指定していても、TCP/IP 経由の接続は暗号化された状態で確立される
local 行で受ける UNIX ドメインソケットの接続にも、同じサーバ証明書による暗号化が適用される
pg_hba.conf に hostnossl の行が無いかぎり、非SSL の接続要求は認証の前に拒否される
SSL による接続を受け付けられる状態になっただけであり、暗号化を強制するには pg_hba.conf の接続種別を hostssl にする必要がある（正解）

解説

ssl = on は SSL 接続を受け付けられるようにする設定にすぎず、暗号化を強制するのは pg_hba.conf の接続種別です。hostssl の行は SSL 接続のときだけ一致し、host は SSL でも非SSL でも一致します（根拠: 学習用テキスト 1-1 通信経路の暗号化（SSL）／サーバ側 ── 「暗号化を要求するか」は pg_hba.conf で決める [G1.1]）。

他の選択肢が誤りである理由

「クライアントが sslmode に何を指定していても、TCP/IP 経由の接続は暗号化された状態で確立される」sslmode の既定は prefer で、サーバが SSL を断れば非SSL で接続します。ssl = on だけでは接続の暗号化は決まりません。
「local 行で受ける UNIX ドメインソケットの接続にも、同じサーバ証明書による暗号化が適用される」SSL/TLS の対象は TCP/IP 接続で、pg_hba.conf の local が受ける UNIX ドメインソケット接続は対象外です。
「pg_hba.conf に hostnossl の行が無いかぎり、非SSL の接続要求は認証の前に拒否される」host の行は SSL でも非SSL でも一致します。非SSL を拒む形にするには hostssl で受けるか、hostnossl の行に reject を書きます。

設問2

クライアントが接続文字列で sslmode=require を指定した。この指定で得られるものと得られないものの説明として適切なものはどれか。

サーバ証明書が信頼された CA の発行であるかどうかまで検証され、なりすましの経路も遮断できる
サーバが SSL に対応していない場合には非SSL の接続へ切り替えて接続が継続される
通信は暗号化されるが接続先サーバの正当性は確認されないため、なりすましを防ぐには verify-full が要る（正解）
サーバ証明書のコモンネームと接続先のホスト名が一致することまで確認される

解説

require は暗号化だけを保証する段で、サーバの正当性は確認しません。CA の検証が加わるのが verify-ca、CA の検証にホスト名の一致まで加わるのが verify-full です（根拠: 学習用テキスト 1-1 通信経路の暗号化（SSL）／クライアント側 ── sslmode の6段 [G1.1]）。

他の選択肢が誤りである理由

「サーバ証明書が信頼された CA の発行であるかどうかまで検証され、なりすましの経路も遮断できる」CA の発行かどうかを検証するのは verify-ca 以上です。require は暗号化の段までで、証明書の中身は見ません。
「サーバが SSL に対応していない場合には非SSL の接続へ切り替えて接続が継続される」断られたときに非SSL へ落ちるのは prefer と allow の挙動です。require はサーバが SSL に対応していなければ接続に失敗します。
「サーバ証明書のコモンネームと接続先のホスト名が一致することまで確認される」ホスト名の一致まで確認するのは verify-full です。require はそこまで見ません。

設問3

稼働中のセッションが実際に SSL で接続されているかを確認したい。方法として適切なものはどれか。

pg_settings で ssl_cert_file と ssl_key_file の値を確認し、両方が読めていれば暗号化されているとみなす
pg_stat_ssl を pg_stat_activity と pid で結合し、接続ごとの ssl 列と暗号スイートを読む（正解）
SHOW ssl の結果が on であれば、その時点でつながっている接続は暗号化されていると判断する
pg_hba.conf の hostssl の行数を数え、その数だけ暗号化された接続が確立していると考える

解説

pg_stat_ssl は接続ごとに1行を持ち、ssl 列でその接続が SSL かどうか、version・cipher・bits で暗号の内容が分かります。pid で pg_stat_activity と結合すればユーザ名やデータベース名と並べて読めます（根拠: 学習用テキスト 1-1 通信経路の暗号化（SSL）／今その接続が暗号化されているかを見る ── pg_stat_ssl [G1.1]）。

他の選択肢が誤りである理由

「pg_settings で ssl_cert_file と ssl_key_file の値を確認し、両方が読めていれば暗号化されているとみなす」pg_settings が返すのは設定値で、個々の接続が暗号化されているかどうかは分かりません。
「SHOW ssl の結果が on であれば、その時点でつながっている接続は暗号化されていると判断する」SHOW ssl は設定値を返すだけです。ssl = on でも sslmode によっては非SSL の接続が混ざります。
「pg_hba.conf の hostssl の行数を数え、その数だけ暗号化された接続が確立していると考える」pg_hba.conf は接続の条件を書いたファイルで、実際に何本が SSL でつながっているかは分かりません。

設問4

テーブルの特定の列だけを暗号化するために pgcrypto を導入した。この構成の説明として適切なものはどれか。

暗号化と復号を SQL で明示的に呼ぶため、log_statement = 'all' にすると鍵がサーバログに残る（正解）
pgp_sym_encrypt で暗号化した値は、crypt と gen_salt を組み合わせて復号する
ディスク上のデータファイルが透過的に暗号化され、SQL からは暗号化の有無を意識せずに読み書きできる
暗号化した列に対しても、B-tree インデックスによる範囲検索がそのまま利用できる

解説

pgcrypto は列単位の暗号化で、鍵（パスフレーズ）は SQL の引数として渡します。そのため log_statement = 'all' にしていると鍵が平文でサーバログに残ります（根拠: 学習用テキスト 1-2 データの暗号化 ── pgcrypto [G1.1]）。

他の選択肢が誤りである理由

「pgp_sym_encrypt で暗号化した値は、crypt と gen_salt を組み合わせて復号する」pgp_sym_encrypt で暗号化した値は pgp_sym_decrypt で復号します。crypt と gen_salt は戻せないハッシュを作る関数です。
「ディスク上のデータファイルが透過的に暗号化され、SQL からは暗号化の有無を意識せずに読み書きできる」ディスクを丸ごと透過的に守るのは OS やファイルシステム側の暗号化の役目です。pgcrypto は SQL で明示的に暗号化と復号を行います。
「暗号化した列に対しても、B-tree インデックスによる範囲検索がそのまま利用できる」暗号化した列は毎回の復号が必要になるため、範囲検索やインデックスによる絞り込みは実質使えません。

設問5

データページのチェックサムについての説明として適切なものはどれか。

ignore_checksum_failure を on にすると、検査値の合わないページが読み出し時に修復される
ページの改ざんを検知して不正な書き換えを拒み、保存されたデータの秘匿にも使われる
postgresql.conf の data_checksums を on にして再起動すれば、稼働中のクラスタでも有効にできる
有効化できるのは initdb の時点だけで既定は無効であり、状態は SHOW data_checksums で分かる（正解）

解説

チェックサムは initdb に --data-checksums（-k）を付けたときだけ有効になり、既定は無効です。有効かどうかは SHOW data_checksums や pg_controldata で確認します（根拠: 学習用テキスト 1-2 データの暗号化 ── pgcrypto／チェックサムは暗号化ではない ── initdb --data-checksums (-k) [G1.1]）。

他の選択肢が誤りである理由

「ignore_checksum_failure を on にすると、検査値の合わないページが読み出し時に修復される」ignore_checksum_failure はエラーを警告に格下げして読み進めるだけで、壊れたページの中身は戻りません。
「ページの改ざんを検知して不正な書き換えを拒み、保存されたデータの秘匿にも使われる」チェックサムは壊れたことに気づくための仕組みで、データを秘匿する働きはありません。
「postgresql.conf の data_checksums を on にして再起動すれば、稼働中のクラスタでも有効にできる」チェックサムは稼働中のパラメータでは変えられません。クラスタ作成時の initdb で決まります。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← OSS-DB Gold の資格ページへ