Document

モデル変換に基づく
セキュリティ要求の実現保証
February 7, 2009 (Sat.)
07TA518K - 上條和幸
目次
• 1. 関連技術
– 1-1. モデル駆動型工学
– 1-2. セキュリティ要求
• 2. 研究背景・目的
• 3. セキュリティ要求の実現
• 4. 結論・展望
1
1-1. モデル駆動型工学
• より抽象的なモデル(PIM)からより具体的な
モデル(PSM)への変換の繰り返し。
– 抽象的 = コンピュータ、プログラミング言語等か
らの制約を受けない。
• モデル変換はモデル変換規則に従って実行。
– 変換記述言語にはATLを使用する。
2
ATLによる変換
• ATLはMOFモデルに対して使用可能。
• MOFの階層構造(図1)
– M3:MetaMetaModel - MOF構造を定義
– M2:MetaModel - Modelを定義
– M1:Model - Model自身
– M0:Reality - Modelのインスタンス
3
図1. MOFの階層構造
4
• ATLでの変換に必要なもの
– ソースモデルのメタモデル (図2)
– ソースモデル (ソース1、図3)
– ターゲットモデルのメタモデル (図4)
– モデル変換規則 (ATLにて記述)
5
モデル変換例
• ソースモデル(PIM) のユースケース図から、
ターゲットモデル(PSM)のクラス図へ。
• モデル変換概要図 (図5)
• モデル変換規則の一部 (ソース2)
• ターゲットモデル (ソース3、図6)
6
図2. ソースモデルのメタモデル
7
ソース1. ソースモデル
8
図3. ソースモデル
9
図4. ターゲットモデルのメタモデル
10
図5. ユースケース図 to クラス図
11
ソース2. ATLによる変換規則の一部
12
ソース3. ターゲットモデル
13
図6. ターゲットモデル
14
1-2. セキュリティ要求
• ISO/IEC 27002 : 2005
– 経済協力開発機構の「情報セキュリティ・ガイドラ
イン」で定義されている3つのセキュリティ目的
(CIA)を反映。
– 更に、ISO/IEC TR 13335で定義されているCIA
を補完する3つのセキュリティ目的(AAR)を含め
てもよい。
15
CIA
• Confidentiality
– 情報にアクセスすることが許可された者だけがアクセスで
きることを確実にすること。
• Integrity
– 情報及び処理方法の正確さ及び完全である状態を安全
防護すること。
• Availability
– 許可された利用者が必要なときに情報にアクセスできる
ことを確実にすること。
16
AAR
• Authenticity
– 利用者、プロセス、システム及び情報又は資源の
身元が主張どおりであることを保証すること。
• Accountability
– 主体の行為からその主体にだけ至る形跡をたど
れることを保証すること。
• Reliability
– 意図した動作と結果に整合性があること。
17
2. 研究背景・目的
• セキュリティ要求はソフトウェアの安全性と密
な関係。
• セキュリティ要求に関するモデル変換が失敗
的に実行された場合、想定し、対処していた
はずの脅威に晒される。
• モデル変換の失敗例とその対処法を探る。
18
3. セキュリティ要求の実現
• セキュリティ要求文から実装機能への置き換
えは研究範囲外。
• PIMとPSM共にクラス図。
– PIMとPSMの差はセキュリティ要求の実現度。
• ソースモデル、ターゲットモデル (図7、図8)
19
モデル変換時の問題点
• あるモデル変換規則を適用することで、別の
モデル変換規則が適用不可となる。
• モデル変換規則の適用そのものは実行され
たが、意図したモデルとならなかった。
20
図7. ソースモデル
VideoBrowser
User
- name : String
+ play() : void
+ stop() : void
+ pause() : void
+ search() : void
+ upload() : void
+ download() : void
Video
- id : String
- name : String
- size : int
21
図8. ターゲットモデル
LoginController
+ checkUserName() : void
+ startSession() : void
Role
- id : String
VideoBrowser
User
- name : String
+ play() : void
+ stop() : void
+ pause() : void
+ search() : void
+ upload() : void
+ download() : void
Video
- id : String
- name : String
- size : int
Permission
- roleid : String
- videoid : String
- permissioninfo : boolean
22
モデル変換規則1 (図9)
• クラス”User”とクラス”VideoBrowser”との関
連を適用ポイントに指定。
• 新規クラス”LoginController”を作成し、その
クラスと、適用ポイントである関連の参照先ク
ラス(”User”, “VideoBrowser”)に対し新たな
関連を作成。
• 適用ポイントである関連自身を削除。
23
図9. モデル変換規則1
LoginController
+ checkUserName() : boolean
+ startSession() : void
VideoBrowser
User
- name : String
+ play() : void
+ stop() : void
+ pause() : void
+ search() : void
+ upload() : void
+ download() : void
Video
- id : String
- name : String
- size : int
24
モデル変換規則2 (図10)
• クラス”User”とクラス”VideoBrowser”との関
連を適用ポイントに指定。
• 新規クラス”Role”を作成し、そのクラスと、適
用ポイントである関連の参照先クラス(”User”,
“VideoBrowser”)に対し新たな関連を作成。
• 適用ポイントである関連自身を削除。
25
• クラス”VideoBrowser”を適用ポイントに指定。
• 新規クラス”Permission”を作成し、そのクラス
と適用ポイントであるクラスに対し、新たな関
連を作成。
26
図10.モデル変換規則2
VideoBrowser
User
Role
- name : String
- id : String
+ play() : void
+ stop() : void
+ pause() : void
+ search() : void
+ upload() : void
+ download() : void
Video
- id : String
- name : String
- size : int
Permission
- roleid : String
- videoid : String
- permissioninfo : boolean
27
• 適用されなかったモデル変換規則に関しての
情報を得ることが必要。
• ATLはモデル変換規則が適用される際に同
時に実行されるプログラムを ”do” の中に記
述できる。(ソース4)
– 事前にモデル変換規則リストを用意。
– 適用したモデル変換規則を ”do” で出力し差分を
取る。
28
ソース4. ATLのモデル変換規則記述法
29
別の変換アプローチ
• クラス図を拡張して、適用ポイント指定要素をメタモ
デルに追加する。 (図11)
• このアプローチは、
– 適用ポイントと離れている要素と用意に関連を持たせるこ
とが可能。
– モデル変換後に拡張要素を削除することで、通常のクラ
ス図を得ることが可能。
– IDでクラスを指定しているので、ソースモデルの各要素の
名称変更にも対応可能。
30
図11. 拡張クラス図メタモデル
31
• モデル変換規則1、2の適用ポイントに、追加
したTransformation要素を指定。
• 2つの変換規則適用自体はできる。(図12)
32
図12. 意図しないターゲットモデル
LoginController
+ checkUserName() : boolean
+ startSession() : void
VideoBrowser
User
Role
- name : String
- id : String
+ play() : void
+ stop() : void
+ pause() : void
+ search() : void
+ upload() : void
+ download() : void
Video
- id : String
- name : String
- size : int
Permission
- roleid : String
- videoid : String
- permissioninfo : boolean
33
• 拡張メタモデルを使用する場合でも、『2つ以
上のモデル変換規則』が、『同じ適用ポイント
において生じる』際に、失敗的なモデル変換
が起こりうる。
– モデル変換を複数回に分割。
– モデル変換規則を成功的に行えるように合併。
– 2つ以上のモデル変換規則を持つ場合は保留。
34
4. 結論・展望
• 実装に近づくほど、人の判断が重要になってくる。し
かし、ある程度は機械的サポートが欲しい。適用箇
所が分かるのは割りと有効。
• セキュリティ関係なしに、モデル変換一般として利用
することも可能。
• 現時点では、モデルの部分ごとについてのセキュリ
ティのみに焦点を当てているので、モデル(システ
ム)全体的な見方が必要。
35

Download Report