セキュリティ対策と権限管理
intra-martでは重要な業務データを扱うため、適切なセキュリティ対策が不可欠です。ここでは、システム内外におけるセキュリティ対策を理解し、正しく権限を設定することで、不正アクセスの防止や安全な運用につなげます。
intra-martのセキュリティ対策
intra-martでは、さまざまなセキュリティ対策が提供されています。ここでは、製品外で行う対策の検討と、製品内での対策の一部について説明します。
製品外の対策を検討する
intra-martを構築する上では、サーバ構成およびミドルウェア（OS、JDK、データベース、Webブラウザなど）に関するセキュリティを、事前に担保しておくことが重要です。初期構築時だけでなく、その後の運用も考慮した対策を検討することが求められます。利用開始後も、各ベンダが提供する修正プログラムの適用など、適宜対応してください。
また、intra-martの基盤上で動作する、個別開発アプリケーションや連携先アプリケーションについても、セキュリティ（脆弱性）対策が必要です。各アプリケーションの開発側においても、適切な対策を講じてください。
影響やインパクトの大きい脆弱性が発見された場合、セキュリティ上のリスクが高まる可能性があります。これらの情報については、「intra-mart Support (FAQ) - intra-mart Accel Platform > 脆弱性」で公開していますので、定期的に確認してください。
製品内の対策を確認する
intra-martでは、さまざまな脆弱性に対して、あらかじめセキュリティ対策が講じられています。ここでは、intra-martにおける製品側のセキュリティ対策について説明します。
セキュリティ対策の基本方針
製品リリース前
製品リリース前は、設計・開発・テストの各段階で脆弱性対策を実施します。独立行政法人 情報処理推進機構（IPA）が提供する情報セキュリティにおける脆弱性対策のガイドラインに準拠して、開発・テストを実施します。
IPAが提供する脆弱性対策のガイドラインは、「IPA 情報セキュリティ > 安全なウェブサイトの作り方」を参照してください。
製品リリース後
製品リリース後は公開・運用の段階となり、脆弱性が発見された場合には緊急パッチの提供や次期バージョンの修正などにより対応します。過去1年分のアップデートに対しても補填を検討します。これは、発生した問題に対して対処する「対応・是正」の対策です。
原則として、セキュリティ対策の基本方針に基づき提供されるセキュリティ修正プログラムによって、既存の動作仕様が変更されることはありません。ただし、セキュリティ上の理由により、一部の動作が変更される場合があります。
代表的な脆弱性と対策例
【対策例1】 SQLインジェクション
SQLインジェクションとは、アプリケーションがデータベースへ送るSQL文に悪意ある入力を混入させ、不正な操作を行う攻撃のことです。攻撃を受けると、「情報漏えい」「改ざん」「消去」など、深刻な被害につながる可能性があり、Webアプリケーションの脆弱性の中でも代表的で重大なものの一つです。
これは、入力値がSQLとして実行されてしまうことが原因となるため、intra-martでは、ユーザが入力する箇所に対して、SQLインジェクションを考慮したサニタイジング（無害化）処理を行うことで対策しています。また、一部の管理者向けの機能においては、不正なSQLが入力されるリスクが存在しますが、権限管理によってアクセスを厳密に制御することでリスクを低減する必要があります。
【対策例2】 バッファオーバーフロー
バッファオーバーフローは、用意されているメモリ領域（バッファ）のサイズを超えてデータを書き込んでしまうことで、プログラムの動作が破壊されたり、意図しない処理が実行される脆弱性の一種です。
intra-mart製品はJavaで実装されており、メモリ管理がランタイム環境によって制御されるため、低レイヤ言語で発生しやすい不正なメモリ領域への直接アクセスは原理的に起こりにくい構造となっています。このため、バッファオーバーフローのリスクは比較的低いとされています。
intra-martではSQLインジェクションやバッファオーバーフロー以外にも、さまざまな脆弱性への対策が講じられています。詳細は「intra-martで運用する場合のセキュリティの考え方 - 2.2. intra-mart製品（パッケージ部分）」を参照してください。
intra-martの権限管理
intra-martのアプリケーションに関連するアクセス権限の管理は、権限・認可設定で行います。intra-martでは、管理者による権限・認可設定により、意図したユーザのみが機能を利用できる状態を制御し、権限を厳密に管理することで、セキュリティ対策の一環としてアクセス制御を実現しています。
また、intra-martでは「認可」によってユーザに紐づく権限を厳密に管理しています。これにより、不正なリクエストがあった場合でも、許可された範囲内の情報にのみアクセスできる構造となっています。
たとえば、メニューや標準アプリケーション（IM-LogicDesignerやIM-BloomMakerなど）へのアクセスは、これらの権限・認可設定によってコントロールされています。実際に「認可設定」画面を確認しながら、「どのような設定を行うと、どのように動作するか」という観点で理解することが重要です。
なお、アプリケーションに対するアクセス制御を行う場合は、IM-Authz（認可）による設定が必要となります。用途や要件に応じて、適切に認可設定を行ってください。ただし、アプリケーションのカスタマイズや設定ミスによってはリスクが残る可能性があるため、十分に注意してください。
IM-Authz（認可）情報のインポート・エクスポート機能は、認可設定をファイルとして出力・取り込みすることで、環境間の移行やバックアップ、設定の再利用を可能にします。詳細は、「IM-Authz（認可）インポート・エクスポート仕様書」を参照してください。
ロールと認可の関係
intra-martにおける「ロール」は、「このユーザはどの機能を利用できるか／どの操作が可能か」といった役割をグループ化したものです。ロールには、「管理者」「一般利用者」「申請承認者」などがあり、システムやアプリケーションごとに必要な権限が集約されています。
個別ユーザに直接認可を設定するのではなく、ロールに認可を設定し、ユーザにロールを割り当てるという方法をとることで、効率的かつ適切な権限管理が可能となり、情報セキュリティの観点でも有効となります。 また、ロールは個別ユーザだけでなく、組織やグループ単位にも付与することができます。
intra-martにおけるアプリケーションの各機能へのアクセス権限は、管理者が認可設定により付与します。標準では、ロールに対して認可を設定し、そのロールをユーザに割り当てることで、さまざまな管理者・ユーザの権限を管理します。詳細は「intra-mart管理者の種類と役割」を参照してください。
認可設定の仕組み
intra-martの認可設定とは、システムやアプリケーション内の各機能や画面（リソース）に対して、「誰が」「何を」「どうする」といったアクセス権限「許可」「禁止」を制御する仕組みです。これにより、ユーザごとに操作を適切に制限し、セキュリティと利便性を両立できます。
intra-martでは、基本的にすべての画面や処理に対してリソースを定義し、認可設定を行うことを前提としています。また、1つのリソースに複数の画面を紐づけることも可能なため、要件に応じて柔軟な運用が可能です。
認可設定は、「認可設定」画面で、「誰が（サブジェクト）」「何を（リソース）」「どうする（アクション）」を設定します。
誰が（サブジェクト）
サブジェクトとは、「誰が」を表すエンティティです。ユーザ（個人）、ロール、組織（会社・部門）、サブジェクトグループなど、認可対象となる主体を指します。認可の判断では、サブジェクトに紐づく属性（所属組織、割り当てられたロール、グループ構成など）を参照して、「許可」「禁止」を決定します。
サブジェクトタイプ
intra-mart標準で提供しているサブジェクトタイプは、以下のとおりです。
| 区分 | サブジェクトタイプ名 | テーブル名 |
|---|---|---|
| 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 |
何を（リソース）
リソースとは、保護対象の「何を」に相当します。画面・処理、メニュー、ポートレット、Webサービスの関数、テーブルアクセスなど、アクセス制御の対象となる実体を表します。リソースは、さらにリソースグループを用いて権限設定を階層的にまとめることができます。また、各リソースには一意のリソースURI（認可URI）が設定されます。
「リソースグループID」と「リソースURI」は異なる項目です。認可の判定には、リソースURIが使用されます。リソースURIを設定しない場合は「リソースグループ」として登録され、認可設定画面で個別に割り当てることができません。そのため、再登録が必要となる場合があります。
認可を適切に行うためには、リソースの種類が「何に対するものか」（例：画面へのアクセス、処理の実行など）や、設定によって「どのような動作になるのか」を理解することが重要です。
たとえば、「IM-共通マスタ - マスタメンテナンス」というリソースに対して認可設定を行う場合を考えます。マスタを管理するユーザは「テナント管理者」、マスタを参照するユーザは「一般ユーザ（認証済みユーザ）」というように、役割ごとに操作範囲を分けたいケースを想定します。
このような場合、リソースとアクション（参照・管理など）を組み合わせて認可を設定します。その結果、権限を付与されたユーザ（サブジェクト）は、対象のリソースに対して、許可されたアクションのみを実行できるようになります。
また、リソースの詳細を確認すると、リソースはリソースグループによって階層的に整理されており、関連する機能単位でまとまって管理されていることがわかります。これにより、認可設定を体系的に把握しやすくなります。
リソースタイプ
intra-mart標準で提供している代表的なリソースタイプは、以下のとおりです。
| リソースタイプ名 | タイプキー | 説明 | |
|---|---|---|---|
| 画面・処理 | service | Web画面や画面に紐づく処理（JSP・アクション・コントローラなど）を対象とするリソース。最も一般的な画面アクセス制御に使用 | |
| テナント管理 | メニュー | im-menu-group | メニューやメニューグループの表示（ナビゲーション要素）を制御するリソース |
| ポータル | ポータル | im-portal-portal | ポータルの表示を制御するリソース |
| ポートレット | im-portal-portlet | ポータル上のポートレット（表示部品）の表示を制御するリソース | |
| ポートレット編集モード | im-portal-portlet-editmode | ポータル上のポートレット（表示部品）の編集を制御するリソース | |
| IM-共通マスタ | 会社 | im_master | マスタデータ単位（会社）の表示を制御するリソース |
| ユーザプロファイル | im-master-user-profile | マスタデータ単位（ユーザプロファイル）の表示を制御するリソース | |
| 個人プロファイル | im-master-user-self-profile | マスタデータ単位（個人プロファイル）の表示を制御するリソース | |
| IMBox | IMBox | imbox-auth | IMBoxの表示を制御するリソース |
| IM-LogicDesigner | IM-LogicDesigner REST API | im-logic-rest | IM-LogicDesignerのフローをREST APIとして利用するためのルート情報に紐づくリソース |
リソースタイプには、それぞれ定義されたアクションが存在します。アクションとは、サブジェクトがリソースに対して行う操作を表す識別子であり、認可ではこのアクション単位で「許可」「禁止」を制御します。代表的なアクションについては、下記「リソースタイプごとの代表的なアクション例」を参照してください。
リソースグループ
リソースグループは、リソースを階層的に管理するための構造情報です。これにより、複数のリソースに対してまとめて認可設定を行うことができます。また、認可機構のAPIを使用してリソースを作成すると、対応するリソースグループが1つ作成されます。リソース自体は名称や情報を持たず、これらの情報は対応するリソースグループに保持されます。そのため、APIモデル上では、リソースは「リソースグループとリソースの組み合わせ」として扱われます。
リソースグループは階層構造を持ち、最上位のリソースグループとその配下のツリー全体を「リソースグループセット」と呼びます。リソースグループセットは、権限管理のためにあらかじめ分類・予約されたリソースのまとまりであり、画面やWebサービス、ポートレットなど、同種の機能をまとめて扱うための単位です。
具体的な構造としては、「フォルダ（リソースグループセット）」→「サブフォルダ（リソースグループ）」→「ファイル（リソース）」のような階層になっており、フォルダ単位で「誰が」と「何を（閲覧・実行など）」を設定できます。
管理者は、リソースグループセットおよびその配下のリソースグループに対して権限ポリシーを設定し、その設定は子要素へ継承されます。なお、子要素に個別の設定がある場合は、そちらが優先されます。
このように、同じ種類の機能に対して一括でアクセス制御を適用できることで、設定の手間やミスの削減につながります。
intra-mart標準で提供しているリソースグループセットは、以下のとおりです。
| リソースグループセット名 | リソースグループセットID | 説明 |
|---|---|---|
| 画面・処理 | http-services | 画面表示要素およびそれに対応するサーバ側処理やアクションをまとめたリソース群 |
| HTTPサービス（設定不可） | http-services-unmanaged | プラットフォームが固定で提供する変更不可のHTTPエンドポイント群 |
| Webサービス | web-services | 外部・内部システムと連携するためのSOAP/RESTなどのサービス定義 |
| メニューグループ | im-menu-group | メニュー項目を分類・管理し、画面表示を構成する単位 |
| IM-共通マスタ 会社リソース | im-master | システム全体で参照される会社情報を管理する共通マスタ資源 |
| ポータル | im-portal-portal | ユーザ向けダッシュボードや情報配置を行う統合画面基盤 |
| ポートレット | im-portal-portlet | ポータル上に配置される機能コンポーネント（ウィジェット） |
| ポートレット編集モード | im-portal-portlet-editmode | ポータル上でポートレットの配置や設定を変更する編集状態 |
| IMBox | imbox-auth | ユーザの受信箱や通知、業務案件を一覧・操作する機能群 |
| IM-LogicDesigner REST API | im-logic-rest-api | IM-LogicDesignerで作成したロジックをREST経由で呼び出すAPI群 |
どうする（アクション）
アクションとは、サブジェクトがリソースに対して実行する操作を表す識別子（文字列）を指します。実行・管理・参照などの操作を、権限によって制御します。たとえば、リソースタイプによって、対応する操作が異なります。
- 「画面・処理」の場合：「実行」操作
- 「IM-共通マスタ 会社」の場合：「参照」「編集」操作
このように、リソースタイプごとに「定義アクション（定義済みアクション）」が用意されています。認可URIやポリシーでは、これらのアクション単位で「許可」「禁止」を設定します。
よく使用される代表的なアクション
認可設定では、目的に応じて適切なアクションを選択する必要があります。以下に、主な用途ごとのアクションの選択例を示します。
- 表示だけ制御したい場合：
reader/read - 実際の処理実行やURLアクセスを停止したい場合：
execute - 編集だけ禁止したい場合：
edit/writer - 管理操作を特別扱いしたい場合：
admin
アクションの選択は、制御したい対象や動作に応じて適切に行うことが重要です。リソースタイプやアプリケーションの仕様も踏まえ、意図した動作となるよう設定してください。
リソースタイプごとの代表的なアクション例
アクションは、リソースタイプに依存しています。主なリソースタイプと代表的なアクション例の一部について紹介します。
| リソースタイプ名 | タイプキー | アクション例 | |
|---|---|---|---|
| 画面・処理 | service | 実行（execute） | |
| テナント管理 | メニュー | im-menu-group | 参照（read）、管理（admin） |
| ポータル | ポータル | im-portal-portal | 参照（execute） |
| ポートレット | im-portal-portlet | 利用（execute） | |
| ポートレット編集モード | im-portal-portlet-editmode | 実行（execute） | |
| IM-共通マスタ | 会社 | im_master | 参照（reader）、編集（writer） |
| ユーザプロファイル | im-master-user-profile | 参照（reader） | |
| 個人プロファイル | im-master-user-self-profile | 参照（reader）、編集（writer） | |
| IMBox | IMBox | imbox-auth | 利用（execute） |
| IM-LogicDesigner | IM-LogicDesigner REST API | im-logic-rest | 実行（execute） |
アクションはリソースタイプごとに定義されています。上記で紹介した以外のリソースタイプについては、 「認可仕様書 - intra-mart Accel Platform に含まれるリソースタイプ」を参照してください。