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