セキュリティ要求の記述とセキュリティ要求モデルへの注入 (Step 2) 本ツールは、代表的な認証認可のモジュールの提供するコマンドと、その振る

舞いをライブラリとしてサポートすることで、セキュリティ検証モデルにそれら の振る舞いを反映させている。

Railsでのアクセス制御の実装には、2.5.5節で示したように、アプリケーショ

ンが独自に実装する場合と既存のパッケージの利用とがある。認可の実装方法、つ まりポリシーの記述に関しては、CanCanのようにポリシーをコード中に埋め込む 方法と、データベースを使い柔軟に設定できるようにする方法とがある。CanCan の場合、当初はそのポリシー記述からポリシーを抽出する方法をとったが、実際 のアプリケーションでは不明確な定義が多く見受けられた。これは、ポリシーを Rubyの条件文で自由に記述できることが原因である。それに対し、TheRoleは、

データベースのテーブルで定義するため曖昧さは少なくなるが、データベースに ポリシーを設定するまでは分析ができない。独自実装の場合は、ソースコードや データベースの内容による分析を汎用的にサポートすることは困難である。そこ で、本ツールでは、アクセス制御ポリシーも含め、最低限のセキュリティ要求を独 自に定義する。また、CanCanやTheRoleのような既存パッケージの場合は、本 ツールで利用パッケージ向けのポリシー定義（コードやデータベースの初期値）を 自動生成することも可能である。

ポリシーの記述は、初期の実装ではRuby（によるハッシュ定義）を用いたが、

最新の実装ではツールへの入力はJSONに統一した。実例を 4.2節の Listing4.3 に示すが、個々のモデルに対して、認証認可の有無、RBACの場合はそのアクセ ス制御リストの定義、HTMLや状態遷移図で出力する際の色などを指定する。

一般的に、この定義が複雑になるのは認証認可に関する部分が主であり、既存 の認証認可パッケージを利用する場合は、対応するテンプレートを利用すること で開発者の負担は低減されると考える。

生成されるセキュリティ検証モデルのクラス図を図4.2に示す。制御フローモデ ルはアプリケーションの全体の振る舞いを示す状態遷移図となる。データフローモ デルはアプリケーションへの入出力を中心としたデータの流れの記録である。実

際には、双方のモデルはクラス図にあるようにツール内部でインスタンスを共有 している。

セキュリティ検証モデル上では由来の異なる2つのポリシーを管理している。ひ とつは、ソースコードから抽出されたもの、もう一つは、要求定義から生成し、各 状態に付与されたものである。これらは、状態(State)、変数(Variable)、モデル

(Model)に割り当てられる。この２つのポリシーの整合性をチェックすることで、

セキュリティ要求と実装の各種整合性を確認するのが、本ツールの大きな特徴で ある。

図 4.2: 生成されるセキュリティ検証モデルのクラス図