モデル変換に基づく セキュリティ要求の実現保証

Post on 01-Jan-2016

28 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

モデル変換に基づく セキュリティ要求の実現保証. February 7, 2009 (Sat.) 07TA518K - 上條 和幸. 目次. 1. 関連技術 1-1. モデル駆動型工学 1-2. セキュリティ要求 2. 研究背景・目的 3. セキュリティ要求の実現 4. 結論・展望. 1-1. モデル駆動型工学. より抽象的なモデル (PIM) からより具体的なモデル (PSM) への変換の繰り返し。 抽象的 = コンピュータ、プログラミング言語等からの制約を受けない。 モデル変換はモデル変換規則に従って実行。 - PowerPoint PPT Presentation

TRANSCRIPT

モデル変換に基づくセキュリティ要求の実現保証

February 7, 2009 (Sat.)07TA518K - 上條 和幸

2

目次

• 1. 関連技術– 1-1. モデル駆動型工学– 1-2. セキュリティ要求

• 2. 研究背景・目的• 3. セキュリティ要求の実現• 4. 結論・展望

3

1-1. モデル駆動型工学

• より抽象的なモデル (PIM) からより具体的なモデル (PSM) への変換の繰り返し。

– 抽象的 = コンピュータ、プログラミング言語等からの制約を受けない。

• モデル変換はモデル変換規則に従って実行。

– 変換記述言語には ATL を使用する。

4

ATL による変換

• ATL は MOF モデルに対して使用可能。

• MOF の階層構造 ( 図 1)– M3:MetaMetaModel - MOF 構造を定義– M2:MetaModel - Model を定義– M1:Model - Model 自身– M0:Reality - Model のインスタンス

5

図 1. MOF の階層構造

6

• ATL での変換に必要なもの

– ソースモデルのメタモデル ( 図 2)– ソースモデル ( ソース 1 、図 3)– ターゲットモデルのメタモデル ( 図 4)– モデル変換規則 (ATL にて記述 )

7

モデル変換例

• ソースモデル (PIM) のユースケース図から、ターゲットモデル (PSM) のクラス図へ。

• モデル変換概要図 ( 図 5)

• モデル変換規則の一部 ( ソース 2)

• ターゲットモデル ( ソース 3 、図 6)

8

図 2. ソースモデルのメタモデル

9

ソース 1. ソースモデル

10

図 3. ソースモデル

11

図 4. ターゲットモデルのメタモデル

12

図 5. ユースケース図 to クラス図

13

ソース 2. ATL による変換規則の一部

14

ソース 3. ターゲットモデル

15

図 6. ターゲットモデル

16

1-2. セキュリティ要求

• ISO/IEC 27002 : 2005

– 経済協力開発機構の「情報セキュリティ・ガイドライン」で定義されている 3 つのセキュリティ目的 (CIA) を反映。

– 更に、 ISO/IEC TR 13335 で定義されているCIA を補完する 3 つのセキュリティ目的(AAR) を含めてもよい。

17

CIA

• Confidentiality– 情報にアクセスすることが許可された者だけがアク

セスできることを確実にすること。

• Integrity– 情報及び処理方法の正確さ及び完全である状態を安

全防護すること。

• Availability– 許可された利用者が必要なときに情報にアクセスで

きることを確実にすること。

18

AAR

• Authenticity– 利用者、プロセス、システム及び情報又は資源

の身元が主張どおりであることを保証すること。

• Accountability– 主体の行為からその主体にだけ至る形跡をたど

れることを保証すること。

• Reliability– 意図した動作と結果に整合性があること。

19

2. 研究背景・目的

• セキュリティ要求はソフトウェアの安全性と密な関係。

• セキュリティ要求に関するモデル変換が失敗的に実行された場合、想定し、対処していたはずの脅威に晒される。

• モデル変換の失敗例とその対処法を探る。

20

3. セキュリティ要求の実現

• セキュリティ要求文から実装機能への置き換えは研究範囲外。

• PIM と PSM 共にクラス図。– PIM と PSM の差はセキュリティ要求の実現

度。

• ソースモデル、ターゲットモデル ( 図 7 、図 8)

21

モデル変換時の問題点

• あるモデル変換規則を適用することで、別のモデル変換規則が適用不可となる。

• モデル変換規則の適用そのものは実行されたが、意図したモデルとならなかった。

22

図 7. ソースモデル

- name : String

User

- size : int- name : String- id : String

Video

+ download() : void+ upload() : void+ search() : void+ pause() : void+ stop() : void+ play() : void

VideoBrowser

23

図 8. ターゲットモデル

- name : String

User

+ startSession() : void+ checkUserName() : void

LoginController

- id : String

Role

+ download() : void+ upload() : void+ search() : void+ pause() : void+ stop() : void+ play() : void

VideoBrowser

- size : int- name : String- id : String

Video

- permissioninfo : boolean- videoid : String- roleid : String

Permission

24

モデル変換規則 1 ( 図 9)

• クラス” User” とクラス” VideoBrowser”との関連を適用ポイントに指定。

• 新規クラス” LoginController” を作成し、そのクラスと、適用ポイントである関連の参照先クラス (”User”, “VideoBrowser”)に対し新たな関連を作成。

• 適用ポイントである関連自身を削除。

25

図 9. モデル変換規則 1

- name : String

User

- size : int- name : String- id : String

Video

+ download() : void+ upload() : void+ search() : void+ pause() : void+ stop() : void+ play() : void

VideoBrowser

+ startSession() : void+ checkUserName() : boolean

LoginController

26

モデル変換規則 2 ( 図 10)

• クラス” User” とクラス” VideoBrowser”との関連を適用ポイントに指定。

• 新規クラス” Role” を作成し、そのクラスと、適用ポイントである関連の参照先クラス (”User”, “VideoBrowser”) に対し新たな関連を作成。

• 適用ポイントである関連自身を削除。

27

• クラス” VideoBrowser” を適用ポイントに指定。

• 新規クラス” Permission” を作成し、そのクラスと適用ポイントであるクラスに対し、新たな関連を作成。

28

図 10. モデル変換規則 2

- name : String

User

- id : String

Role

+ download() : void+ upload() : void+ search() : void+ pause() : void+ stop() : void+ play() : void

VideoBrowser

- size : int- name : String- id : String

Video

- permissioninfo : boolean- videoid : String- roleid : String

Permission

29

• 適用されなかったモデル変換規則に関しての情報を得ることが必要。

• ATL はモデル変換規則が適用される際に同時に実行されるプログラムを ” do” の中に記述できる。 ( ソース 4)

– 事前にモデル変換規則リストを用意。– 適用したモデル変換規則を ” do” で出力し差

分を取る。

30

ソース 4. ATL のモデル変換規則記述法

31

別の変換アプローチ

• クラス図を拡張して、適用ポイント指定要素をメタモデルに追加する。 ( 図 11)

• このアプローチは、

– 適用ポイントと離れている要素と用意に関連を持たせることが可能。

– モデル変換後に拡張要素を削除することで、通常のクラス図を得ることが可能。

– ID でクラスを指定しているので、ソースモデルの各要素の名称変更にも対応可能。

32

図 11. 拡張クラス図メタモデル

33

• モデル変換規則 1 、 2 の適用ポイントに、追加した Transformation 要素を指定。

• 2 つの変換規則適用自体はできる。 ( 図12)

34

図 12. 意図しないターゲットモデル

- name : String

User

- id : String

Role

+ download() : void+ upload() : void+ search() : void+ pause() : void+ stop() : void+ play() : void

VideoBrowser

- size : int- name : String- id : String

Video

- permissioninfo : boolean- videoid : String- roleid : String

Permission

+ startSession() : void+ checkUserName() : boolean

LoginController

35

• 拡張メタモデルを使用する場合でも、『 2 つ以上のモデル変換規則』が、『同じ適用ポイントにおいて生じる』際に、失敗的なモデル変換が起こりうる。

– モデル変換を複数回に分割。– モデル変換規則を成功的に行えるように合併。

– 2 つ以上のモデル変換規則を持つ場合は保留。

36

4. 結論・展望

• 実装に近づくほど、人の判断が重要になってくる。しかし、ある程度は機械的サポートが欲しい。適用箇所が分かるのは割りと有効。

• セキュリティ関係なしに、モデル変換一般として利用することも可能。

• 現時点では、モデルの部分ごとについてのセキュリティのみに焦点を当てているので、モデル ( システム ) 全体的な見方が必要。

top related