HOME»応用情報技術者試験掲示板»令和4年秋期 午後問6
投稿する
[3947] 令和4年秋期 午後問6
3taiさん(No.1)
https://www.ap-siken.com/kakomon/04_aki/pm06.html
設問3のjについて
質問①
grantをテーブルとユーザでしか設定したことがないのですが、回答例のように列ごとにgrantを設定する方法が全DBに用意されているのか
質問②
回答例のように設定した場合、ADMINでの他列へのSELECTは出来ないのか
他列へのSELECTができないとしたら、なぜその様な設定にするのか
質問③
UPDATE,DELETE,INSERTが不要な理由はなぜか
問題文には書いてないが、使わなくなったデータを残して新しい契約IDを採番するとしたら、DELETEやUPDATEが不要な理由は（百歩譲って）分かりますが、INSERTが不要な理由が分かりません
設問3のjについて
質問①
grantをテーブルとユーザでしか設定したことがないのですが、回答例のように列ごとにgrantを設定する方法が全DBに用意されているのか
質問②
回答例のように設定した場合、ADMINでの他列へのSELECTは出来ないのか
他列へのSELECTができないとしたら、なぜその様な設定にするのか
質問③
UPDATE,DELETE,INSERTが不要な理由はなぜか
問題文には書いてないが、使わなくなったデータを残して新しい契約IDを採番するとしたら、DELETEやUPDATEが不要な理由は（百歩譲って）分かりますが、INSERTが不要な理由が分かりません
2023.02.05 16:58
あわあわさん(No.2)
こんにちは。
まず①についてですが、そもそも応用情報技術者で使用されるSQL文は次のように書かれています。
試験で使用するデータベース言語は，次の仕様に従う。
SQL :JIS X 3005 規格群
引用：「試験で使用する情報技術に関する用語・プログラム言語など」Ver.5.0
https://www.jitec.ipa.go.jp/1_13download/shiken_yougo_ver5_0.pdf
そのため、JIS X 3005 規格群に沿ったSQLを記述できるDBでは使用できるのではないかと思います。
次に②についてですが、ADMINでの他列への参照はできなくなると思います。
なぜそのような設定にする必要があるのかというと、
セキュリティにはユーザに最小限の権限を持たせることで
セキュリティ強度をあげるという考え方があります。
その権限が必要な人にしか必要な機能を触らせないよってことですね。
これをすることによって、内部不正やうっかりミスを防ぐことができます。
例えば、今回の問題で言えば、表2項番4の課題のようなものが、
防げるようになるということですね。
また、③ですが、問題文には、
「表3のアクセス制御を設定するためのSQL文」と書かれています。
表3のアクセス制御に関しては、項番1と項番5に
「上長（ユーザーアカウント名：ADMIN）による参照が必要」
とだけ書かれています。
よって、問題通りに考えれば、表3のアクセス制御の設定は参照以外の権限は要りません。
ですので、UPDATEやDELETE、INSERTは必要ないのだと思います。
まず①についてですが、そもそも応用情報技術者で使用されるSQL文は次のように書かれています。
試験で使用するデータベース言語は，次の仕様に従う。
SQL :JIS X 3005 規格群
引用：「試験で使用する情報技術に関する用語・プログラム言語など」Ver.5.0
https://www.jitec.ipa.go.jp/1_13download/shiken_yougo_ver5_0.pdf
そのため、JIS X 3005 規格群に沿ったSQLを記述できるDBでは使用できるのではないかと思います。
次に②についてですが、ADMINでの他列への参照はできなくなると思います。
なぜそのような設定にする必要があるのかというと、
セキュリティにはユーザに最小限の権限を持たせることで
セキュリティ強度をあげるという考え方があります。
その権限が必要な人にしか必要な機能を触らせないよってことですね。
これをすることによって、内部不正やうっかりミスを防ぐことができます。
例えば、今回の問題で言えば、表2項番4の課題のようなものが、
防げるようになるということですね。
また、③ですが、問題文には、
「表3のアクセス制御を設定するためのSQL文」と書かれています。
表3のアクセス制御に関しては、項番1と項番5に
「上長（ユーザーアカウント名：ADMIN）による参照が必要」
とだけ書かれています。
よって、問題通りに考えれば、表3のアクセス制御の設定は参照以外の権限は要りません。
ですので、UPDATEやDELETE、INSERTは必要ないのだと思います。
2023.02.06 10:03
GinSanaさん(No.3)
★AP プラチナマイスター
設問3のjについて
質問①
ANSI側で規定はされている（※）が、例えばSQLITEはGRANT自体がないので当然ないので、全DBで必ずANSIにまんま従わないといけないか？というとそうでもない。OracleでEXCEPTがなくてMINUSしかないのと似ている
ちなみにOracleでは列指定は可能
※
github.com/crate/sql-99/blob/55ee2e51d91e8201109f9f1a74ea0a9e4b402532/docs/chapters/15.rst#grant-statement
できない。
例）
試験としてストレートに言えば、表3のアクセス制御に
他に見たければ運用管理担当者のユーザーアカウントを使えということが推察される（運用管理担当者のユーザーアカウントに対しては適切なアクセス制御が設定されているものとする）
実際の現場ではこんなことをやっていたら日が暮れるので銀行でもこんなのは10年そこらでもやってなかったので、見たことはないが、やってるとこはやっているのだろう、たぶん・・・
運用管理担当者でやるんじゃないですか。
質問①
>grantをテーブルとユーザでしか設定したことがないのですが、回答例のように列ごとにgrantを設定する方法が全DBに用意されているのか
ANSI側で規定はされている（※）が、例えばSQLITEはGRANT自体がないので当然ないので、全DBで必ずANSIにまんま従わないといけないか？というとそうでもない。OracleでEXCEPTがなくてMINUSしかないのと似ている
ちなみにOracleでは列指定は可能
※
github.com/crate/sql-99/blob/55ee2e51d91e8201109f9f1a74ea0a9e4b402532/docs/chapters/15.rst#grant-statement
<privileges> ::=
<object privileges> ON <Object name>
<Object name> ::=
[ TABLE ] <Table name> |
DOMAIN <Domain name> |
CHARACTER SET <Character set name> |
COLLATION <Collation name> |
TRANSLATION <Translation name> |
TYPE <UDT name> |
<specific routine designator>
<object privileges> ::=
ALL PRIVILEGES |
<action> [ {,<action>}... ]
<action> ::=
DELETE |
SELECT [ (<Column name> [ {,<Column name>} ... ]) ] |
INSERT [ (<Column name> [ {,<Column name>} ... ]) ] |
UPDATE [ (<Column name> [ {,<Column name>} ... ]) ] |
REFERENCES [ (<Column name> [ {,<Column name>} ... ]) ] |
TRIGGER |
UNDER |
USAGE |
EXECUTE
<object privileges> ON <Object name>
<Object name> ::=
[ TABLE ] <Table name> |
DOMAIN <Domain name> |
CHARACTER SET <Character set name> |
COLLATION <Collation name> |
TRANSLATION <Translation name> |
TYPE <UDT name> |
<specific routine designator>
<object privileges> ::=
ALL PRIVILEGES |
<action> [ {,<action>}... ]
<action> ::=
DELETE |
SELECT [ (<Column name> [ {,<Column name>} ... ]) ] |
INSERT [ (<Column name> [ {,<Column name>} ... ]) ] |
UPDATE [ (<Column name> [ {,<Column name>} ... ]) ] |
REFERENCES [ (<Column name> [ {,<Column name>} ... ]) ] |
TRIGGER |
UNDER |
USAGE |
EXECUTE
>質問②
>回答例のように設定した場合、ADMINでの他列へのSELECTは出来ないのか
できない。
例）
docs.oracle.com/cd/E16338_01/server.112/b56299/statements_9013.htm
GRANT REFERENCES (employee_id),
UPDATE (employee_id, salary, commission_pct)
ON hr.employees
TO oe;
この結果、ユーザーoeは、employee_id列、salary列およびcommission_pct列の値を更新できるようになります。ユーザーoeは、employee_id列を参照する参照整合性制約を定義することもできます。ただし、GRANT文にはこれらの列のみが指定されているため、ユーザーoeはemployees表の他の列を操作できません。
GRANT REFERENCES (employee_id),
UPDATE (employee_id, salary, commission_pct)
ON hr.employees
TO oe;
この結果、ユーザーoeは、employee_id列、salary列およびcommission_pct列の値を更新できるようになります。ユーザーoeは、employee_id列を参照する参照整合性制約を定義することもできます。ただし、GRANT文にはこれらの列のみが指定されているため、ユーザーoeはemployees表の他の列を操作できません。
>他列へのSELECTができないとしたら、なぜその様な設定にするのか
試験としてストレートに言えば、表3のアクセス制御に
上長(ユーザーアカウント名：ADMIN)による参照が必要
とあるから、上長のアカウントとしての操作はパスワードを見るくらいしかないと推測される。他に見たければ運用管理担当者のユーザーアカウントを使えということが推察される（運用管理担当者のユーザーアカウントに対しては適切なアクセス制御が設定されているものとする）
実際の現場ではこんなことをやっていたら日が暮れるので銀行でもこんなのは10年そこらでもやってなかったので、見たことはないが、やってるとこはやっているのだろう、たぶん・・・
>質問③
>UPDATE,DELETE,INSERTが不要な理由はなぜか
>問題文には書いてないが、使わなくなったデータを残して新しい契約IDを採番するとしたら、DELETEやUPDATEが不要な理由は（百歩譲って）分かりますが、INSERTが不要な理由が分かりません
運用管理担当者でやるんじゃないですか。
2023.02.06 12:18
3taiさん(No.4)
あわあわ様
返信投稿ありがとうございます。
私が運用とユーザ権限について深く考えすぎていたようです。
定義書の文字通り指定された列に参照(SELECT)のみ許可すればよかったってことですね...。
INSERTやUPDATEが可能なもっと上位のユーザがいるんでしょうが、あまり深く考えすぎないようにします。
返信投稿ありがとうございます。
私が運用とユーザ権限について深く考えすぎていたようです。
定義書の文字通り指定された列に参照(SELECT)のみ許可すればよかったってことですね...。
INSERTやUPDATEが可能なもっと上位のユーザがいるんでしょうが、あまり深く考えすぎないようにします。
2023.02.06 12:27
3taiさん(No.5)
GinSana様
返信投稿ありがとうございます。
列ごとのGRANT設定の仕様を知らなかったので勉強になりました。ありがとうございます。
運用管理担当者の上長がADMINなので運用管理担当者がパスワードの登録更新できたらまずいと思います。なのでADMINとは別の権限があるユーザがあるのではないかと勝手に思っております。
返信投稿ありがとうございます。
列ごとのGRANT設定の仕様を知らなかったので勉強になりました。ありがとうございます。
運用管理担当者の上長がADMINなので運用管理担当者がパスワードの登録更新できたらまずいと思います。なのでADMINとは別の権限があるユーザがあるのではないかと勝手に思っております。
2023.02.06 12:41