見出し画像

情報処理安全確保支援士 令和2年 秋 午後2 問1を解説してみた(セキュアプログラミング/SAML)

それでは、情報処理安全確保支援士 令和2年 秋 午後2 問1(セキュアプログラミング/SAML)の解説を始めていきます(^^)

本文は一通り読んでいることを前提に設問部分から解説していきます。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2020r02_oct/2020r02o_sc_pm2_qs.pdf

設問3ではセキュアプログラミング(JAVA)が取り上げられています。

プログラミングで必要なことは、
ただ「動く」だけでなく、不正なアクセスに対する防御策を考えることも大切です。

特に金銭や個人情報を扱う場合はなおさら重要なってきます。

今回はセキュアプログラミング(JAVA)の基礎を学ぶ上では
オブジェクト指向も合わさり良い問題なのでYouTubeに解説アップします。
(JAVAの基礎(オブジェクト指向)が分かっていないと厳しいとおもうので
 JAVAの基礎知識がある人を対象としています)

■設問3(セキュアプログラミング)動画解説■

https://youtu.be/IqY44gEMxfY

設問1

画像1

とあるので表2を見ていきましょう

画像2


以下の 図と紐づけながら見る必要があります。

画像5


FW-P のルールについてで ヒントとしては 項番2の送信元がWeb-Q、Web-Rの書きっぷりがヒントとなります。


画像3

各サイトで上記の紐づけ画面があって、サイトP→サイトQを紐づけるときの画面が上記となります。
上記は、サイトP→サイトQのアカウント紐づけですが、

画像6

本文中のもんごんよりサイトP→QとサイトP→Rの紐づけがあり それを各サイトのLDAPに直接問い合わせる必要があります
 よって LDAP-Q と LDAP-R は通信でひつようになります。

ただ、忘れがちなのが、結果を自分自身のLDAPに書き込むことも要件としてあるので、 WEBーP→LDAP-Pとの間にFWがあるので こちらも開放する必要があります。
プロトコルは LDAP (項番2参照)となります。

よって、

画像7

設問2

画像7

個人情報保護関連について記載されている部分を確認していきましょう。

画像8

なぜ、同意を得る必要があるかということを法的観点で答える必要があります。
以下、サイトに禁止事項の概略があります。
https://www.komon-lawyer.jp/support/compliance/personal/

画像9

いままで個人情報を使っていたのは、各サイトの範囲内で、今回は他サイトまで範囲をひろげるのでそのことに関する同意を得る必要があります。
上記のことを纏めると以下が模範解答になります。

画像10

設問3

画像11

プログラム部分抜粋

画像53

画像54

画像55

まずは、セキュアプログラミングの内容を説明しておきます。
JAVAの基礎が分かっていればそれほど難しい問題ではありませんので、セキュアプログラミング系の見本問題のようなイメージです。

採点講評に「情報処理安全確保支援士はセキュリティ観点でソースコードレビューも行えること」とありますので、セキュアプログラミングも勉強するのがベストです(今のところ避けて通れる道ですが、、)

画像12

プログラムは上記の画面(Web-P)がLDAP-Qに問い合わせて OKなら紐づけを行うプログラム。

処理の流れでプログラムを追っていきましょう
【認証OKの場合の流れ】
まずは、値の初期化処理で AccountLinkクラスのインスタンスidPairが生成されます。

画像13

上記のインスタンス生成時の処理として以下が呼ばれます。
引数の数と型が一致しているので11行目以降のコンストラクタの一緒に実行されます。

画像14

AccountLinkクラスのNO_ERRORをresultに入れています。

画像15

以下が対応しているので 0 の数字が設定されます。

画像16

for分に突入です returnされないかぎり 3回ループします。
 <4 とありますが、3回目がおわって次にいくときに retryCount(3)が+1されて retryCount(4)<4 がfalseとなるのでループを抜けます。 なので3回 (今回の問題では特に関係なし)

画像17

画像18

idPairインスタンスの checkChildメソッドがよばれるのでその部分を追っていきます。
int型(数値)を返却し 例外NamingExceptionを返却する可能性があるメソッドです。

画像19

初期化時に設定したchildSiteオブジェクト(String型)がsiteQまたは siteRの文字列と一致するかのチェックになります。一致すれば true 不一致なら falseを返却します(Stringクラスのメソッドでの仕様で知っていて当たり前のレベル)

画像20

19行目の判定結果で true(つまり siteQ or siteR)でなければ 

画像22

の値を返却し、当メソッドの処理は終了となります。

画像21

siteQ or siteRならば 次の処理に進みます。
24行目以降はsiteQの場合に行われる処理なので、こちらを追っていきます。

画像23

26行目 からsite!Auth メソッドがよばれています。紐づけ先のサイトにID、PASSを連英紙 認証OKならchildChecked を trueに 認証NGならchildChecked を falseに設定します。
もし連携処理時に例外が発生した場合は NamingExceptionを呼び出し元に返却します。

画像24

画像25

今回はOK(認証成功)時なので34行目に進みます。
childCheckedが trueでなければ(つまりfalse 認証失敗ならば) 35行目に進み

画像27

を返却します。
childCheckedが trueなら(つまり 認証成功ならば) 37行目に進み

画像28

を返却します。

画像26

以下はsiteRの処理でsiteQと中身は同じ、defaultはサイトQ、R以外のしょり

画像29

上記の処理でresultにtrue、falseのいずれかが入ります。
checkChildで例外発生時は110行目に飛び 一定時間終了後にもう一度実行ます。(ループは抜けていない 最大3回実行)
 認証が成功した場合はforのループを107行目のbrakeで抜けます。
認証失敗時の処理は省略されています。

画像30


idPairインスタンスのchildCheckedがtrueでなければ(つまりfalseなら) つまり認証NGなら 

画像32

を返却

画像31

116行目以降は、return条件より、ここまで行きつくのはidPair.childCheckedがtrueの時(基本的には認証がOKの時※後で問題点あり)

画像33

画像34

ここまで読み取れたら設問は容易に解けると思いますのでやっていきましょう


画像35

利用者IDの設定の流れなので
以下の部分が該当します

画像37

画像36

画像38

※図4のインスタンス名で答える必要があるので
c ウ idPair.childID
d ア idPair.checkChild


画像39

ヒントは、「何らかの理由」「再試行」とあるので、例外処理だと考えられます。

画像40

例外を発生させるのは siteQAuthなので 26行目 (e ウ)で例外名は NamingException (f ケ) となります


画像41

常に例外が発生(3回ループとも)した場合の問題点は
はじめに初期値と設定した

画像42

のままであること、なので最後の登録処理まで進んでしまうこと

画像43

なので idPair.childChecked (g イ)がtrueのままなので117行目(h キ)まで進み紐づけが実行されてしまうということ。

設問4

画像44

画像47

画像45

・①→本人であることの確認情報が少なすぎる
 ②→ パスワードそのものをメールで送る
3つめを答える問題
ヒントは 一部の利用者はパスワード失念時にログインできなくなるということ。②より 「指定されたメールアドレスに」パスワードを送ることという可能性が高いことから、3つめはメール関連だと想像がつく。


一般的に、パスワード失念時は、既に登録されているアドレスに初期化URLを送信するのがよく見るパターンなので、一般常識と掛け合わせて答える必要がある。

まとめると

画像46

画像48

画像49

画像50

アカウント情報が乗っ取られた場合の被害で「共用利用」とあるので全サイトで考える必要がある。ヒントは甚大なとあるので金銭面である可能性が高い
表1と突き合わせて大きな被害が発生するものを確認する。


画像51

よって

画像52

設問5

こちらは以前の動画でSAMLについて説明しているのでそれを理解していたら容易に解ける問題。


https://www.youtube.com/watch?v=OYfx585CGFs&feature=emb_title



この記事が気に入ったらサポートをしてみませんか?