intra-martにおけるセキュリティ対策
システムを運用する上で、セキュリティ対策は重要です。ここでは、intra-martで構築したシステム全体に関するセキュリティについて確認します。
intra-martにおけるセキュリティの考え方
intra-martでは、製品に対してさまざまなセキュリティ対策を行っています。製品での対応と、製品外でのセキュリティ対策の一部を解説します。
intra-mart外のセキュリティ
intra-martのシステムを構築する上で必要なサーバ構成およびミドルウェア（OS、JDK、データベース、ブラウザなど）についてのセキュリティは、事前に担保しておく事が重要です。
初期構築時のみではなく、その後の運用も考慮した対策の検討が必要です。利用開始後も各ベンダーから提供される修正プログラムの適用などで、適宜対応してください。
intra-mart製品基盤上で動作する個別に開発したアプリケーションおよび連携先アプリケーションについても、開発された側でのセキュリティ（脆弱性）対策が別途必要です。
影響やインパクトの大きい脆弱性については、以下のFAQでも周知されますので適宜確認してください。
「intra-mart support intra-mart Accel Platform 脆弱性」
intra-mart内部の設定
intra-mart製品のセキュリティ（脆弱性）対策を確認してみましょう。
セキュリティ対策の基本方針
- 製品リリース前： 独立行政法人 情報処理推進機構（IPA）のガイドライン（「情報セキュリティ > 安全なウェブサイトの作り方」）に準拠して開発・テストを実施
- 製品リリース後： 脆弱性が発見された場合には緊急パッチや次期バージョンで修正。過去1年分のアップデートに対しても補填が検討される
原則として、上記の基本方針によって提供されたセキュリティ修正プログラムで、既存の動作仕様が変わることはありません。
代表的な脆弱性とその対策例を記載します。
対策例：SQLインジェクション
SQLインジェクションは、「アプリケーションがデータベースへ送るSQL文に、悪意ある入力を混入させて不正操作を行う攻撃」のことです。攻撃されると「情報漏えい」「改ざん」「消去」など致命的被害を被ってしまう、Webアプリケーションの脆弱性の中でも最も有名で深刻なものの一つです。
これは「入力値がSQLとして実行されてしまう」問題なので、intra-martでは、通常ユーザが入力する箇所については、SQLインジェクションを想定したサニタイジング（無害化）処理を行ったアプリケーションを作成しています。
また、一部管理者向けの機能にて悪意あるSQLが入れられてしまうリスクがありますが、下記「intra-martの権限管理を知る」にて、権限管理によるアクセス権の厳密な運用によって、リスク回避を行う必要があります。
対策例：バッファオーバーフロー
バッファオーバーフローは、用意されているメモリ領域（バッファ）を超えてデータを書き込んでしまうことで、プログラムの動作を破壊したり、攻撃者のコードが実行されてしまう脆弱性のことです。
intra-mart製品は、Javaで作成されています。通常は、不正なメモリ領域へアクセスするようなパラメータの侵入を困難にしている対策を行っています。
その他、intra-martのセキュリティに対する考え方についての詳細は
「intra-martで運用する場合のセキュリティの考え方 - 2.2. intra-mart製品（パッケージ部分）」を参照してください。
intra-martの権限管理を知る
intra-martのアプリケーションに関連するアクセス権限の設定を行うのが、「権限・認可設定」機能 です。
intra-mart内では、管理者による権限・認可設定で 「意図したユーザのみが機能に触ることができる状態」 を制御し、アクセス権の厳密な管理をすることで、セキュリティ対策の1つを実行しています。
intra-mart は 「認可」 によってユーザに紐づく権限を厳密に管理しています。これにより、不正なリクエストがあっても、ユーザに許可された範囲内の情報にしかアクセスできない構造になっています。
ただし、アプリケーションのカスタマイズや設定ミスによってはリスクが残る可能性があるため、十分に注意し、適切に設定してください。
認可についての詳細は、「IM-Authz（認可）インポート・エクスポート仕様書」を参照してください。
たとえば、メニューや標準アプリケーション（IM-LogicDesignerやIM-BloomMakerなど）へのアクセスは、intra-martの権限・認可設定でコントロールが可能です。
実際に認可設定画面を確認しながら「このような設定をしたらこう動く」という仕組みについて理解しましょう。
ロールとは
「intra-martの管理者の種類と役割」で説明した通り、intra-martにおけるアプリケーションの各機能へのアクセス権限は、管理者が「認可」機能で設定します。標準では 「ロール（役割）」 に対して 「認可」 を設定し、さまざまな管理者・ユーザを作成します。
intra-martの 「ロール」 は、「このユーザはこういった機能が使える/この操作ができる」という 「役割」をグループ化したもの です。
ロールには、例えば「管理者」「一般利用者」「申請承認者」など、システムやアプリケーションごとに機能を使うための権限が集約されています。
個別ユーザに直接認可を与えるよりも、「ロールにまとめて認可→ユーザにはロール付与」 という形が、情報セキュリティの観点でも重要です。
また、ロールは個別ユーザ以外にも、組織やグループ単位への付与も可能です。
実際の運用においてのロールの役割については、「マスタデータの検討 > ロール」で説明しています。
認可設定とは
intra-martの「認可設定」とは、システムやアプリケーション内の各機能や画面（リソース）に対して、「誰が」「何を」「どうする」といったアクセス権限（許可・禁止）を制御する仕組みです。 これにより、業務運用において適切に利用者ごとに操作を制限し、セキュリティと利便性を両立できます。 intra-mart製品は、基本的に全ての画面や処理についてリソースを定義し、適切に認可設定を行うことを前提としています。1リソースに対して複数画面を紐づけることも可能なので、要件に応じて柔軟な運用が可能です。
認可設定画面
次は、認可設定を理解する上で重要な「誰が / サブジェクト」「何を / リソース」「どうする / アクション」 の詳細を確認しましょう。
誰が / サブジェクト
サブジェクトとは、「誰が」を表すエンティティです。ユーザ（個人）、ロール、組織（会社/部門）、サブジェクトグループなど、 認可対象となる主体すべて を指します。
認可判断では、サブジェクトに紐づく属性（所属組織、割当ロール、グループ構成など）を参照して許可・禁止を決めます。
サブジェクトには、以下のような種類があります。
- ユーザ・ロール・会社組織・役職・パブリックグループ・ゲストユーザ・認証済みユーザ
- パブリックグループ役割
- IPv4アドレス
- 期間
intra-mart Accel Platform が標準的に提供しているサブジェクトタイプ
| 区分 | サブジェクトタイプ名 | テーブル名 |
|---|---|---|
| IM共通マスタ | ユーザ | imm_user |
| 会社組織 | imm_department | |
| 役職 | imm_company_post | |
| パブリックグループ | imm_public_grp | |
| パブリックグループ役割 | imm_public_grp_role | |
| テナント管理 | ロール | b_m_role |
| IPv4 アドレス | im_authz_ipv4 | |
| 認証 | im_authz_meta_subject | |
| 期間 | im_authz_term | |
| プロジェクトチーム機能 | プロジェクト | imprj_project |
何を / リソース
リソースとは、保護対象の「何を」に相当します。画面、処理（service）、メニュー、ポートレット、Webサービスの関数、テーブルアクセスなど、アクセス制御したい実体 を表します。
「リソース」は、さらに「リソースグループ」を使用して権限設定を階層的にまとめることができ、リソース自身には一意のリソースURI（認可URI）が設定されます。
下記の画像は、「ローコード開発チュートリアルガイド - 4.4. ゼロからアプリケーションを作成する」で作成したアンケートアプリケーションのリソース例です。
このリソースはアンケートアプリケーションの回答画面のものです。権限設定をすることにより、権限を与えられたユーザ（サブジェクト）がアンケート回答画面（リソース）の参照や編集・管理（アクション）を行うことが可能になります。
「リソースグループID」と「リソースURI」は別物です。認可問い合わせではリソースURIを使用します。
リソースURIを設定しないと「リソースグループ」として登録され、認可画面で個別割当できず、登録し直しが必要になる場合があります。
認可を適切に行うには、リソースの種類が何に対するものなのか（例：画面にアクセスするためか、処理を行うためか など）、「これを設定したら何がどう動くか」を理解することが重要です。
intra-martで利用する標準的なリソースタイプや、リソースグループセットを確認しましょう。
リソース
intra-mart Accel Platform が標準的に提供しているリソースタイプ
| リソースタイプ名 | タイプキー | 説明 |
|---|---|---|
| 画面・処理 | service | Web画面や画面に紐づく処理（JSP/アクション/コントローラなど）。最も一般的な画面アクセス制御用 |
| テナント管理/メニュー | im-menu-group | メニューやメニューグループの表示（ナビゲーション要素） |
| Webサービス/API | webservice | 外部呼び出し可能なサービス/API の呼び出し単位 |
| ポータル/ポートレット | im-portal-portlet | ポータル上のポートレット（表示部品）の表示/編集 |
| IM共通マスタ/会社 | im_master | マスタデータ単位（会社、組織マスタなど）に対する権限 |
| テーブル保守/データアクセス | tablemaintenance | DBテーブルの保守操作やテーブルベースの画面（CRUD操作） |
| ビュー・帳票 | view | 帳票や出力ビューの表示・生成 |
| カスタム（独自）リソースタイプ | 任意定義/設定追加 | 製品標準にない独自要件を持つリソース。authz-resource-type-config などの設定ファイルでリソースタイプ定義を追加可能 |
これらのリソースタイプはそれぞれ定義されたアクションがあり、下記 「リソースタイプごとの代表的なアクション例」 で代表的なものを確認できます。
リソースグループ
リソースグループ は、リソースを階層化する構造情報です。これにより、ある程度まとまったリソースに対して認可設定を行うことができます。
認可機構に対してAPIを使ってリソースを作成すると、リソースと対になるリソースグループが1つ作成されます。
リソースは名称や説明を持ちません。リソースと対になっているリソースグループが、リソースの名称や説明にあたる情報を保持します。 このため、APIモデル上ではリソースとはリソースグループとリソースのセットの事を意味します。
リソースグループは階層構造をとっていますが、階層の先頭のリソースグループとその配下のツリーを 「リソースグループセット」 と呼称しています。
リソースグループセットは、「権限管理のためにあらかじめ分類・予約されたリソースのまとまり」で、似た種類の機能（画面・Webサービス・ポートレット など）をまとめて扱うための単位です。
フォルダ（グループセット）→ サブフォルダ（リソースグループ）→ ファイル（個々の画面やAPI）のような階層になっていて、フォルダ単位で誰が何を（閲覧・実行など）できるかを決められる仕組みです。
管理者は「グループセット」やその下のグループに対して権限ポリシーを設定し、それが子要素に継承されます。子に個別設定があればそちらが優先されます。
「同じ種類の機能に一括でアクセス制御を適用できる」ことにより、設定の手間やミスを減らすことが目的です。
intra-mart Accel Platform が標準的に提供している代表的なリソースグループセット
| リソースグループセット名 | 説明 |
|---|---|
| 画面・処理 | 画面表示要素とそれに対応するサーバ側処理やアクションをまとめたリソース群 |
| HTTPサービス（設定不可） | プラットフォームが固定で提供する変更不可のHTTPエンドポイント群 |
| Webサービス | 外部/内部システムと連携するためのSOAP/RESTなどのサービス定義 |
| メニューグループ | メニュー項目を分類・管理して画面表示を構成する単位 |
| IM共通マスタ 会社リソース | システム全体で参照する会社情報を管理する共通マスタ資源 |
| ポータル | ユーザ向けダッシュボードや情報配置を行う統合画面基盤 |
| ポートレット | ポータル上に配置する小さな機能コンポーネント（ウィジェット） |
| ポートレット編集モード | ポータル画面でポートレットの配置や設定を変更する編集状態 |
| IMBox | ユーザの受信箱や通知・業務案件を一覧・操作するための機能群 |
| IM-LogicDesigner REST API | IM-LogicDesignerで作成したロジックをREST経由で呼び出すためのAPI群 |
どうする / アクション
アクションとは、「サブジェクト」が「リソース」に対して行おうとする操作を表す識別子（文字列） を指します。実行・管理・参照 など、権限で制御します。
リソースの種類（リソースタイプ）が画面・処理の場合は「実行」、会社一覧などのデータやマスタの場合は、「参照」や「登録・更新」という処理になります。
このように、リソースタイプごとに「定義アクション（定義済みアクション）」があり、認可UIやポリシーでは、そのアクション単位で許可/禁止を設定します。
アクション名はリソースタイプごとに定義されており、名前（大文字・小文字）は厳密に一致させる必要があります。
よく使用されるアクションの種類と、リソースタイプごとの代表的なアクションを見ていきましょう。
よく使われる代表的アクション（一般的な名称と意味）
- execute / invoke：処理や画面の「実行」やサービス呼び出し
- view / access / refer：表示・参照・アクセス（読み取り的操作）
- read：読み取り（データ取得）
- create / insert / register：新規作成・登録
- update / modify：更新・編集
- delete / remove：削除
- edit：編集モードの許可（表示とは別に編集操作を制御したい場合）
- admin / manage：管理者向け操作（設定変更など）
- download / upload：ファイルの取得・アップロード
- query / search：検索・照会系操作
- その他モード系：view-mode / edit-mode など（ポートレット表示/編集モード）
リソースタイプごとの代表的なアクション例
| リソースタイプ | アクション例 |
|---|---|
| 画面・処理（service） | execute（処理実行）、view（表示）など。URLアクセスの可否を制御する場合は execute を用いることが多い（導入しているフレームワークやアプリ側実装に依存） |
| メニュー（menu） | view / access など、メニューの表示可否。メニューを非表示にするだけでは直接URLアクセスを防げない点に注意 |
| Webサービス（API） | invoke / execute / functionName など。関数ごとにリソースURIを作る場合は関数名がアクション扱いになるケースもある。サービス呼び出し単位でリソースURIを作成し、invoke/execute などで制御 |
| テーブル保守（TableMaintenance） | read / insert / update / delete（CRUD）などの、テーブル操作に対応するアクション |
| ファイル管理系 | download / upload / delete / manage など |
| ポートレット（portlet） | view（表示）、edit（編集）、config（設定）など、ポートレットのモードごとに分けられることが多い |
| カレンダー・スケジュール | view / book / manage など。施設カテゴリの参照と登録などで別アクションを使う |
| メッセージ（IMBoxなど） | read / send / delete / admin |
どのアクションを使えばよいか
- 表示だけ制御したい → view / refer / read
- 実際の処理実行やURLアクセスを止めたい → execute（処理実行系）を制御
- 作成/登録を制御したい → create / insert / register
- 編集だけを禁止したい → update / edit
- 管理操作を特別扱いしたい → admin / manage
アクションはリソースタイプに依存しているので、利用するリソースタイプの定義一覧を参照する必要があります。
詳細は以下のドキュメントを参照してください。
「認可仕様書 - 5. 付録 - intra-mart Accel Platform に含まれるリソースタイプ」
ここまでで、intra-martのセキュリティ対策およびそれに連なる権限管理についての概念を確認しました。実際の権限設定の操作については、「3. 初期データの構築」で説明します。
権限設定を行う前に、intra-martを使用するために必要なマスタデータの検討をします。