【z/OS RACF完全ガイド】RACFの全体像を体系的に解説｜基本概念から必須コマンドまで

## はじめに

z/OSを扱うエンジニアにとって、セキュリティの中核をなす **RACF（Resource Access Control Facility）** の理解は避けて通れません。RACFはデータセットやアプリケーションといったあらゆるリソースを保護しています。

しかし、 **「概念が複雑で全体像が掴みにくい」「コマンドが多く、使い分けが難しい」** といった悩みを抱える初学者の方も多いのではないでしょうか。

本記事は、そうした課題を解決するため、RACFの概念から主要コマンドまでを体系的に解説します。読み終える頃には、以下の状態に到達していることを目標とします。

*   RACFがz/OSセキュリティにおいて果たす役割と全体像を把握できる
*   ユーザー、グループ、リソースといった基本要素の関係性を説明できる
*   主要コマンドの役割を理解し、**シナリオに沿って使いこなす手順**までを習得できる

z/OSに携わるエンジニアや、メインフレームのセキュリティを基礎から学びたい方を対象としています。この記事が、RACFを理解するための一助となれば幸いです。


## 第1章：RACFの全体像 - z/OSのセキュリティを司る門番

RACFを理解する第一歩は、その全体像とシステムにおける役割を把握することです。この章では、RACFの目的と機能を解説します。

### 1-1. RACFとは？

RACFは、z/OSに標準で備わっているセキュリティ製品であり、システム上のあらゆる資産（リソース）への不正なアクセスを防止する役割を担っています。 **「誰が（Who）」「何に（What）」「何をできるか（How）」** を管理しています。

現実世界のビルのセキュリティに例えると、RACFは総合受付と警備システムのようなものであると言えます。利用者はまず身分証（**ユーザーID**）を提示して本人であることを証明し、次にその人が持つ入室許可証（**権限**）に基づいて、入れる部屋（**リソース**）とそこでできること（読み取り、書き込みなど）が決定されます。RACFは、この一連のチェックをz/OSの世界で実現しています。

### 1-2. RACFが担う3つの重要な役割「認証・認可・監査」

RACFの機能は、セキュリティの基本原則である「認証」「認可」「監査」という3つの柱で構成されています。

*   **認証（Authentication）**
    「あなたは誰ですか？」を検証するプロセスです。ユーザーIDとパスワードを用いて本人確認を行います。

*   **認可（Authorization）**
    「あなたは何をできますか？」を判断するプロセスです。認証されたユーザーが、特定のデータセットやファイルにアクセスしようとする際に、RACFがその操作（読み取り、更新など）を許可されているか否かをチェックします。

*   **監査（Auditing）**
    「誰が、いつ、何をした（しようとした）か」を記録するプロセスです。許可されたアクセスはもちろん、拒否された不正アクセスの試みもログ（SMFレコード）として記録されます。

これら3つの機能が連携することで、z/OSのセキュリティが守られています。

### 1-3. メインフレームセキュリティにおけるRACFの位置づけ

RACFは単独のアプリケーションではなく、z/OSに統合されています。OSレベルで動作するため、その上で稼働するCICSやDb2といった主要なミドルウェアのセキュリティも一元的に管理します。

他のOSをご存知の方であれば、LinuxにおけるPAMやSELinux、WindowsにおけるActive Directoryのような役割をイメージすると分かりやすいかもしれません。ただし、RACFはよりOSと結合し、z/OS環境全体のアクセス制御を包括的に担う、強力な基盤であると理解してください。アプリケーションごとに個別でセキュリティを実装するのではなく、OSの根幹をなすRACFがすべてのセキュリティ判断を行う。これが基本的な考え方です。

## 第2章：RACFを構成する3つの基本要素

RACFによるアクセス管理は、 **「ユーザー」「グループ」「リソース」** という3つの基本要素によって成り立っています。これらはRACFの骨格をなす重要な概念です。それぞれの役割と関係性を理解することが、RACFを体系的に学ぶ上で重要です。

### 2-1. ユーザー（USER） - システムを利用する「人」

RACFにおける「ユーザー」とは、システムを利用する個人を識別するための単位です。各ユーザーの情報は**ユーザープロファイル**という器に格納され、これによりRACFは一人ひとりを一意に管理します。

ユーザープロファイルは、大きく分けて2つの部分で構成されています。

1.  **基本情報（BASEセグメント）**: 全ユーザーが持つ、ユーザーID、パスワード、デフォルトグループ、所有者といった基本的な情報です。
2.  **追加情報（各種セグメント）**: TSOへのログオンやz/OS UNIXの利用など、z/OSの特定の機能を使うために必要となる専門的な情報を格納する領域です。ユーザーは、利用する機能に応じて必要なセグメントを持つことになります。

#### 代表的なセグメントの役割と設定値

*   **TSOセグメント**: TSO/Eにログオンするために必要な情報を格納します。
    *   **設定の例**: ログオンプロシージャー（`PROC`）、リージョンサイズ（`SIZE`）、アカウント番号（`ACCTNUM`）など。
*   **OMVSセグメント**: z/OS UNIX環境（旧称OMVS）を利用するために必須の情報を格納します。
    *   **設定の例**: ユーザーID番号（`UID`）、デフォルトグループID番号（`GID`）、ホームディレクトリ（`HOME`）、デフォルトシェルプログラム（`PROGRAM`）など。

#### コマンドによる設定と確認

これらのセグメント情報は、ユーザー作成時（`ADDUSER`）または作成後（`ALTUSER`）に設定・変更します。

```text
// USERAにTSOセグメントを追加する例
ALTUSER USERA TSO(PROC(IKJACLEC) SIZE(4096))

// USERBにOMVSセグメントを追加する例
ALTUSER USERB OMVS(UID(101) HOME('/u/userb') PROGRAM('/bin/sh'))
```

プロファイルにどのようなセグメントが定義されているかは、第4章で紹介する`LISTUSER`（`LU`）コマンドで確認できます。例えば `LU USERB OMVS` と実行すれば、`USERB`の`OMVS`セグメント情報だけをピンポイントで確認することが可能です。

このように、ユーザープロファイルは基本情報とセグメント情報の組み合わせで成り立っていると理解してください。

### 2-2. グループ（GROUP） - ユーザーをまとめる「組織」

「グループ」は、複数のユーザーをまとめるための単位であり、効率的な権限管理を実現するための仕組みです。個々のユーザーに直接権限を与えるのではなく、役割やチームに応じたグループを作成し、そのグループに対して権限を付与するのがRACFの基本的な運用スタイルです。これにより、人事異動などがあっても、ユーザーをグループに参加させたり、グループから外したりするだけで済み、管理コストを削減できます。

グループの作成には`ADDGROUP`、ユーザーのグループへの所属には`CONNECT`コマンドを使用します。

```text
ADDGROUP DEVOPS
CONNECT USERA GROUP(DEVOPS)
```
*この例では、`DEVOPS`というグループを作成し、先に作成した`USERA`をそのメンバーとして追加しています。*

### 2-3. リソース（RESOURCE） - 保護対象となる「資産」

「リソース」とは、RACFが保護すべき対象すべての総称です。

最も代表的なリソースはデータセットですが、その他にもz/OS UNIXのファイルやディレクトリ、CICSのトランザクション、Db2のテーブル、さらには特定のシステム操作を実行する権限（`FACILITY`クラス）といった、多種多様な資産がリソースに含まれます。

*   **データセット**: `SYS1.PROCLIB`, `USERA.TEST.DATA` など
*   **z/OS UNIX**: `/u/usera/file1` といったファイルやディレクトリ
*   **CICS**: `CEMT` などのトランザクションコード
*   **FACILITY**: `BPX.SUPERUSER` のような特殊権限

z/OS環境において「保護すべきもの」は、すべて何らかのリソースとしてRACFの管理対象になると理解してください。次の章では、これらのリソースを具体的にどのように保護していくのかを解説します。


## 第3章：アクセス制御の仕組みを理解する
前章では、RACFを構成する3つの基本要素「ユーザー」「グループ」「リソース」について学びました。この章では、それらの要素がどのように連携してアクセス制御を実現するのか、その仕組みを掘り下げていきます。

ここで登場するのが、 **「プロファイル」「アクセスリスト」「クラス」** という、アクセス制御の核となる3つの概念です。これら6つのキーワードの関係性を先に整理しておきましょう。

*   **誰が？**: **ユーザー** （**グループ**に所属）
*   **何に？**: **リソース** （特定の**クラス**という分類に属する）
*   **どう管理する？**:
    1.  リソースは **プロファイル** という単位でRACFに定義・保護されます。
    2.  プロファイルには **アクセスリスト** が設定され、「誰に」「何を許可するか」が記述されます。

**一連の流れで表現すると、以下のようになります。**
> 「**グループ**」に所属する「**ユーザー**」が、特定の「**クラス**」に分類される「**リソース**」にアクセスしようとすると、RACFは、そのリソースを保護している「**プロファイル**」の「**アクセスリスト**」を参照し、アクセスを許可するかどうかを判断します。

あきらめずゆっくり読んでみてください。ゆっくり読むと理解できるはずです。

この関係性を念頭に置いていただくことで、これからの解説がよりスムーズに理解できるはずです。それでは、一つひとつの概念を詳しく見ていきましょう。

### 3-1. 「プロファイル」によるリソースの保護

z/OS上のリソースをRACFの管理下に置くためには、**リソースプロファイル**を作成（定義）する必要があります。このプロファイルが、特定のリソースに対する保護設定を格納する器となります。

プロファイルには、大きく分けて2つの種類があります。

*   **ディスクリートプロファイル**: `USERA.TEST.DATA` のように、一つのリソースを個別に定義するプロファイルです。
*   **総称（Generic）プロファイル**: `USERA.**` や `SYS1.PROD.*.LOAD` のように、ワイルドカード（`*`, `**`, `%`）を用いて複数のリソースをまとめて定義するプロファイルです。管理を効率化するため、実運用では総称プロファイルが多用されます。

リソースプロファイルの作成には、`RDEFINE`コマンドを使用します。

### 3-2. 「アクセスリスト」と権限レベル

プロファイルを作成した直後は、所有者以外は誰もそのリソースにアクセスできない状態です。ここに、特定のユーザーやグループに対してアクセスを許可する設定を追加していくのが**アクセスリスト**の役割です。この設定には`PERMIT`コマンドを使用します。

アクセスを許可する際には、どのレベルの操作を許すかを示す**権限レベル**を指定します。

*   **READ**: 読み取りのみ許可。
*   **UPDATE**: 読み取りに加え、内容の変更や削除を許可。
*   **CONTROL**: `UPDATE`権限に加え、アクセスリストの変更も一部可能。
*   **ALTER**: プロファイルの所有者と同等の最高権限。プロファイルの削除も可能。
*   **NONE**: アクセスを明示的に禁止。

例えば、ユーザー`USERB`にデータセット`USERA.TEST.DATA`への読み取り権限を与える場合は、以下のように指定します。

```text
PERMIT 'USERA.TEST.DATA' CLASS(DATASET) ID(USERB) ACCESS(READ)
```

### 3-3. グループを活用した効率的な権限管理

セキュリティ管理を効率化するには、個々のユーザーではなく**グループに対して権限を付与する**ことが必要です。これにより、人の異動があってもグループのメンバーを変更するだけで済み、権限設定そのものを見直す必要がなくなります。

例えば、`DEVTEAM`という開発者グループに、`TEST.PROJ.**`で示されるすべてのテスト用データセット群への更新権限を与えるシナリオを考えます。

```text
// 1. 総称プロファイルを作成
RDEFINE DATASET 'TEST.PROJ.**' UACC(NONE)

// 2. DEVTEAMグループにUPDATE権限を付与
PERMIT 'TEST.PROJ.**' CLASS(DATASET) ID(DEVTEAM) ACCESS(UPDATE)
```

この設定により、`DEVTEAM`グループに所属するすべてのユーザーは、対象のデータセット群を更新できるようになります。異動が発生した際は、異動するユーザーを`DEVTEAM`グループから除外することで、異動するユーザーが対象のデータセット群を更新できなくするという対応を行います。

### 3-4. リソースを分類する「クラス」の概念
RACFは、リソースを種類ごとに **「クラス」** という **分類** しています。これは、性質の異なるリソース（例：最大44文字のデータセット名と4文字のCICSトランザクション名）を、それぞれに適したルールで管理するための仕組みです。

コマンドでリソースを操作する際は、`CLASS(...)`パラメータでどのクラスのプロファイルを対象とするかを明示的に指定する必要があります。ここでは、代表的なクラスとその役割を紹介します。

*   **`DATASET`**: データセットを保護する最も基本的なクラスです。
*   **`FACILITY`**: z/OS UNIXのスーパーユーザー権限（`BPX.SUPERUSER`）など、特定のシステム機能へのアクセスを制御します。汎用性が高く、様々な権限管理に使用されます。
*   **`TERMINAL`**: TSOにログオンできる端末を制御します。
*   その他、CICSやDb2といったミドルウェアも、それぞれ専用のクラス（`TCICSTRN`, `DSNR`など）を持っています。

このように、`RDEFINE`や`RLIST`といったコマンドで`CLASS(...)`を指定するのは、RACFに対して **「どの分類（クラス）の、どの項目（プロファイル）を操作するのか」** を明確に伝えるためです。この「クラス」を意識することが、RACFを正確に操作する上で重要となります。



## 第4章：TSOで実践！RACF基本コマンドリファレンス
これまでの章で学んだ概念を、TSO環境で実際に操作するための基本コマンドを紹介します。ここでは、コマンドを「定義・変更」「権限設定」「確認・検索」という目的別に分類しました。特に、システムに影響を与えない **「確認・検索」コマンドは、この記事を読みながらご自身の環境で試すことができます。**

なお、コマンドを実行するTSOの画面によっては、コマンドの先頭に`TSO`というプレフィックスを付ける必要があります。例えば、ISPFのパネル上から実行した際に `INVALID COMMAND` といったエラーが表示された場合は、`LU *` を `TSO LU *` のように変更して試してみてください。

>＜＞内は短縮形

### 4-1. ユーザー／グループの定義・変更

システムの「利用者」であるユーザーと、その集合であるグループを定義・変更・削除するためのコマンド群です。

*   **ユーザープロファイルの操作**
    *   `ADDUSER`: `ADDUSER USERA DFLTGRP(SYS1) PASSWORD(pass) OWNER('USER A')`
    *   `ALTUSER`: `ALTUSER USERA SPECIAL` (SPECIAL権限を付与)
    *   `DELUSER`: `DELUSER USERA`
*   **グループプロファイルの操作**
    *   `ADDGROUP`: `ADDGROUP DEVOPS`
    *   `ALTGROUP`: `ALTGROUP DEVOPS OWNER(SYSADMIN)`
    *   `DELGROUP`: `DELGROUP DEVOPS`
*   **ユーザーとグループの関連付け**
    *   `CONNECT` ＜`CONN`＞: `CONNECT USERA GROUP(DEVOPS)`
    *   `REMOVE` ＜`REM`＞: `REMOVE USERA GROUP(DEVOPS)`

### 4-2. リソースの保護定義

システムの「資産」を保護するためのリソースプロファイルを定義・変更・削除するためのコマンド群です。

*   `RDEFINE` ＜`RD`＞: `RDEFINE DATASET 'USERA.TEST.DATA' UACC(NONE)`
*   `RALTER` ＜`RA`＞: `RALTER DATASET 'USERA.TEST.DATA' OWNER(USERB)`
*   `RDELETE` ＜`RDEL`＞: `RDELETE DATASET 'USERA.TEST.DATA'`

### 4-3. アクセス権限の設定

どのユーザーやグループが、どのリソースにアクセスできるかを設定するコマンドです。この操作はシステムのセキュリティに直接影響するため、慎重に実行する必要があります。

*   **`PERMIT` ＜`PE`＞**
    リソースプロファイルのアクセスリストを操作し、アクセス権を付与・削除します。
    *   **権限付与**:
        ```text
        PERMIT 'USERA.TEST.DATA' CLASS(DATASET) ID(DEVOPS) ACCESS(UPDATE)
        ```
    *   **権限削除**:
        ```text
        PERMIT 'USERA.TEST.DATA' CLASS(DATASET) ID(DEVOPS) DELETE
        ```

### 4-4. 情報の確認と検索（参照系コマンド）

ここから紹介するコマンドは、システムの状態を表示・検索するだけで、設定を変更することはありません。日々の運用において最も使用頻度が高く、安全に実行できるコマンド群です。ぜひ、ご自身のTSO環境で実際に試しながら、出力結果を確認してみてください。

これから紹介するコマンドはざっくりと以下のポイントを押さえておくと、目的の情報を効率的に見つけることができます。

* **「プロファイルの中身（詳細）が知りたいときは`LIST`系」**
    * 対象が **ユーザーやグループ** の場合、専用の`LISTUSER`,`LISTGROUP`コマンド
    * 対象が **それ以外のリソース** の場合、`CLASS`を指定しながら`RLIST`コマンド
* **「どんなプロファイルがあるか一覧で見たいときは`SEARCH`」** 


#### `LISTUSER` ＜`LU`＞: ユーザー情報の表示
指定したユーザーのプロファイル情報を表示します。
*   **特定のユーザー情報を表示**
    `LU USERA`
    ユーザー`USERA`の基本情報（デフォルトグループ、所有者、最終アクセス日時、権限など）が表示されます。
*   **自身の情報を表示**
    `LU *`
    現在ログオンしている自身の情報を表示します。自分の権限などを素早く確認する際に非常に便利です。
*   **特定のセグメント情報のみを表示**
    `LU BPXUSER OMVS NORACF`
    z/OS UNIX関連の情報（`OMVS`セグメント）のみを簡潔に表示します。`NORACF`オペランドで基本情報が抑制され、目的の情報だけを抽出できます。

#### `LISTGROUP` ＜`LG`＞: グループ情報の表示
指定したグループのプロファイル情報を表示します。グループに所属するメンバーの確認に不可欠です。
*   **グループ情報と所属メンバーを表示**
    `LG DEVOPS`
    グループ`DEVOPS`の所有者や、`CONNECT INFORMATION`セクションに所属ユーザーの一覧が表示されます。

#### `RLIST` ＜`RL`＞: リソースプロファイル情報の表示
指定したリソースがどのように保護されているかを確認します。
*   **プロファイルの基本情報を表示**
    `RL DATASET SYS1.PROCLIB`
    `SYS1.PROCLIB`のプロファイル基本情報（所有者、UACCなど）が表示されます。
*   **アクセスリストを含む全情報を表示**
    `RL DATASET SYS1.PROCLIB ALL`
    `ALL`オペランドを付与することで、アクセスリスト（`PERMIT`で設定された権限）や統計情報など、すべての詳細情報を確認できます。権限設定の確認には、この形式が必須です。

#### `SEARCH` ＜`SR`＞: 条件を指定したプロファイルの検索
RACFデータベース全体を対象に、様々な条件でプロファイルを検索できるコマンドです。
*   **特定のクラスのプロファイルを検索**
    `SR CLASS(FACILITY)`
    `FACILITY`クラスに定義されているプロファイルを全件検索します。
*   **名前のパターンで検索**
    `SR CLASS(DATASET) MASK(SYS1.**)`
    `MASK`を使用し、`SYS1`で始まるデータセットの総称プロファイルなどを検索します。`*`や`**`といったワイルドカードが利用できます。
*   **時間条件で検索**
    `SR CLASS(USER) WHEN(LOGON(DAYS(90)))`
    `WHEN`を使用し、最終ログオンから90日以上経過したユーザーを検索します。

## 第5章: 実践シナリオで学ぶRACFコマンド操作

これまでの章では、個別のRACFコマンドが持つ機能について学んできました。本章では、それらの知識を活用し、実際の業務で遭遇するであろうシナリオに沿って、一連のコマンド操作の流れを紹介します。

個々のコマンドが、作業フローの中でどのように連携するのかを理解することで、より実践的なスキルを身につけることが本章の目的です。

**【注意】**
この章で紹介するコマンドには、システムの定義を変更するコマンドが含まれます。ご自身の環境で試す際は、テスト用のユーザーIDやリソース名を使用するなど、影響範囲を理解した上で、慎重に実行してください。

---

### 5-1. シナリオ1：新規プロジェクトメンバーの追加

**状況**: 新規プロジェクト`DEVPROJ`が発足し、新しいメンバー`USERC`を追加することになりました。`USERC`はz/OS UNIX環境も利用する想定です。

このシナリオでは、**「グループ作成 → ユーザー作成 → 属性変更」**という基本的な流れと、各ステップでの**確認作業の重要性**を学びます。

#### STEP 1: グループの作成と確認

まず、新しいメンバーを所属させるためのグループを作成します。

```text
// コマンド実行
ADDGROUP DEVPROJ OWNER(SYSADMIN)
```

操作が正しく完了したか、`LISTGROUP`コマンドで確認します。

```text
// 確認コマンド
LISTGROUP DEVPROJ
```
**【確認ポイント】**: `DEVPROJ`というグループが作成され、所有者（OWNER）が意図通り`SYSADMIN`になっていることを確認します。

>OWNERとはその **プロファイルの変更や削除と言った管理権限** を持つ **ユーザーまたはグループ** のことです。`DEVPROJ`というグループに属しているだけのユーザーは`DEVPROJ`というグループプロファイルを変更できません。プロファイルのOWNERとなるグループに所属しているか、`SPECIAL`属性を持つユーザーであればプロファイルを変更できます。

#### STEP 2: ユーザーの作成と確認

次に、作成したグループをデフォルトグループとして指定し、新規ユーザー`USERC`を作成します。

```text
// コマンド実行
ADDUSER USERC DFLTGRP(DEVPROJ) PASSWORD(pass) NAME('NEW MEMBER C')
```

ユーザーが正しく作成されたか、`LISTUSER`コマンドで確認します。

```text
// 確認コマンド
LISTUSER USERC
```
**【確認ポイント】**: `DEFAULT-GROUP`が`DEVPROJ`になっていることや、その他の属性が正しく設定されていることを確認します。

#### STEP 3: ユーザー属性の変更（セグメント追加）と確認

`USERC`がz/OS UNIXを利用できるよう、`ALTUSER`コマンドで`OMVS`セグメントを追加します。

```text
// コマンド実行
ALTUSER USERC OMVS(UID(102) HOME('/u/userc') PROGRAM('/bin/sh'))
```

セグメントが正しく追加されたか、再度`LISTUSER`コマンドで確認します。

```text
// 確認コマンド
LISTUSER USERC OMVS
```
**【確認ポイント】**: `OMVS INFORMATION`セクションが表示され、UIDやHOMEディレクトリが意図通りに設定されていることを確認します。

---

### 5-2. シナリオ2：新規ミドルウェアのリソース保護
**状況**: 新しい監視ツールを導入しました。このツールの管理者機能（リソース名: `NEWTOOL.ADMIN`）へのアクセスを、`SYSADMIN`グループにのみ許可します。このリソースは`FACILITY`クラスで保護することとします。

このシナリオでは、 **「クラスの状態確認 → プロファイル定義 → 権限付与 → 設定の反映」** という、新しいリソースを保護する際の定石を学びます。

#### STEP 1: クラスのアクティブ状態の確認
まず、保護に使用する`FACILITY`クラスが、システムで有効（アクティブ）になっているかを確認します。

```text
// 確認コマンド
SETROPTS LIST
```
**【確認ポイント】**: 出力結果の`ACTIVE CLASSES`のリストに`FACILITY`が含まれているかを確認します。もし含まれていない場合は、以下のコマンドでアクティブ化する必要があります。

```text
// （必要に応じて実行）
SETROPTS CLASSACT(FACILITY)
```

#### STEP 2: プロファイルの作成と確認

次に、保護対象のリソース`NEWTOOL.ADMIN`に対応するプロファイルを`FACILITY`クラスに作成します。`UACC(NONE)`を指定し、デフォルトでは誰もアクセスできないようにするのが基本です。

```text
// コマンド実行
RDEFINE FACILITY NEWTOOL.ADMIN UACC(NONE)
```

`RDEFINE`による変更は、即座にRACFデータベースに書き込まれます。`RLIST`コマンドでデータベース上の定義が正しく行われたかを確認します。

```text
// 確認コマンド
RLIST FACILITY NEWTOOL.ADMIN
```
**【確認ポイント】**: プロファイルが作成され、`UNIVERSAL ACCESS`が`NONE`になっていることを確認します。

#### STEP 3: アクセス権限の付与と確認

`PERMIT`コマンドを使い、`SYSADMIN`グループにこのリソースへのアクセス権（ここでは`READ`）を付与します。この変更も、即座にRACFデータベースに反映されます。

```text
// コマンド実行
PERMIT NEWTOOL.ADMIN CLASS(FACILITY) ID(SYSADMIN) ACCESS(READ)
```

データベース上のアクセスリストが正しく更新されたか、`RLIST`コマンドに`ALL`オプションを付けて確認します。

```text
// 確認コマンド
RLIST FACILITY NEWTOOL.ADMIN ALL
```
**【確認ポイント】**: `ACCESS LIST`のセクションに`SYSADMIN`が`READ`権限で追加されていることを確認します。

#### STEP 4: メモリ上のプロファイルの更新（リフレッシュ）

ここまでの手順で、RACFデータベース上の定義は正しく完了しました。しかし、`FACILITY`クラスのように、パフォーマンス向上のためにプロファイル情報がメモリ上にコピー（キャッシュ）されているクラスがあります。（これを`RACLIST`されている、と呼びます。）

OSやミドルウェアは、アクセスチェックの際にこの高速なメモリ上の情報を参照します。そのため、データベースの定義を変更しただけでは、実際のシステムの動作には反映されません。**稼働中のシステムに変更を適用する**には、以下のコマンドでメモリ上の情報を更新（リフレッシュ）する必要があります。

```text
// コマンド実行
SETROPTS RACLIST(FACILITY) REFRESH
```

この`REFRESH`操作を忘れると、**定義上は正しいにもかかわらず、実際のアクセスチェックでは古い情報が参照され続け、変更が反映されない**という事態に繋がります。`RACLIST`対象クラスのプロファイルを変更した後は、この`REFRESH`が必須の手順となります。

以上で、新規リソースの保護設定とシステムへの反映が完了です。この一連の流れが、新しいアプリケーションやミドルウェアを導入する際の基本的なセキュリティ設定手順となります。


## 第6章：理解度チェック！RACF参照系コマンドクイズ

これまでの章では、RACFの基本的な概念から構成要素、そして具体的なコマンドについて解説してきました。本章では、学習した知識の定着を目的として、実践的なクイズ形式でコマンドの利用方法を確認していきます。

ここで取り上げるのは、主にシステムの状態を参照・確認するためのコマンドです。日常的な運用管理業務において頻繁に使用するものですので、どのような場面でどのコマンドを選択すべきかを意識しながら、ぜひ挑戦してみてください。
>復習
>* **「プロファイルの中身（詳細）が知りたいときは`LIST`系」**
>    * 対象が **ユーザーやグループ** の場合、専用の`LISTUSER`,`LISTGROUP`コマンド
>    * 対象が **それ以外のリソース** の場合、`CLASS`を指定しながら`RLIST`コマンド
>* **「どんなプロファイルがあるか一覧で見たいときは`SEARCH`」** 

---

**問題1：ユーザー情報の確認**

ユーザー`USERA`のプロファイルに定義されている情報、例えばデフォルトグループや最終アクセス日時、所有者などを確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
LISTUSER USERA
```
**【解説】**
`LISTUSER`（`LU`）は、指定したユーザープロファイルの情報を表示する最も基本的なコマンドです。ユーザーの権限（SPECIAL, AUDITORなど）や所属グループ、z/OS UNIXセグメント情報など、多岐にわたる情報を確認する際の起点となります。

---

**問題2：データセットプロファイルとアクセスリストの確認**

データセット`SYS1.PROCLIB`がどのようにRACFで保護されているか、また、どのユーザーやグループにアクセスが許可されているかの詳細（アクセスリスト）まで含めて確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
RLIST DATASET SYS1.PROCLIB ALL
```
**【解説】**
`RLIST`（`RL`）は、指定したリソースプロファイルの情報を表示するコマンドです。`DATASET`クラスのリソースを確認する際は、クラス名の指定が必須です。末尾に `ALL` オペランドを付与することで、プロファイルの基本情報に加え、アクセスリスト（`PERMIT`コマンドで設定された内容）や統計情報など、すべての関連情報を表示させることができます。

---

**問題3：グループ所属メンバーの確認**

グループ`DEVOPS`に、現在どのユーザーが所属（CONNECT）しているか、その一覧を確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
LISTGROUP DEVOPS
```

**【解説】**
`LISTGROUP`（`LG`）は、指定したグループプロファイルの情報を表示します。このコマンドにより、そのグループの所有者（OWNER）や上位グループ（SUPGROUP）といった基本情報と共に、「CONNECT INFORMATION」セクションで所属ユーザーの一覧を確認することが可能です。

---

**問題4：自身の権限の確認**

現在TSOにログオンしている自分自身が、どのようなRACFの特殊権限（SPECIAL、AUDITOR、OPERATIONSなど）を持っているかを確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
LISTUSER *
```


**【解説】**
`LISTUSER`コマンドでユーザーIDの代わりにアスタリスク（`*`）を指定すると、現在ログオンしているユーザー自身の情報を表示します。わざわざ自分のユーザーIDをタイプする必要がなく、管理者権限の有無などを素早く確認したい場合に非常に便利です。

---

**問題5：特定クラスのプロファイル情報の確認**

z/OS UNIXのスーパーユーザー権限を制御する`FACILITY`クラスのプロファイル`BPX.SUPERUSER`の情報を確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
RLIST FACILITY BPX.SUPERUSER
```


**【解説】**
`RLIST`コマンドは`DATASET`クラスだけでなく、`FACILITY`や`TERMINAL`など、あらゆるリソースクラスのプロファイル情報を確認するために使用します。このように、クラス名とプロファイル名を正確に指定することが重要です。

---

**問題6：総称プロファイルの検索**

`SYS1`から始まる名前を持つデータセットに対して、どのような総称（Generic）プロファイルが定義されているか、その一覧を確認したい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**
```
SEARCH CLASS(DATASET) MASK(SYS1)
```


**【解説】**
`SEARCH`コマンドは、指定した条件に合致するプロファイルを検索するための強力なコマンドです。`CLASS(DATASET)`で検索対象をデータセットクラスに絞り、`MASK(SYS1)`で`SYS1`という文字列で始まるプロファイルを検索対象としています。これにより、`SYS1.*`や`SYS1.**.**`といった、影響範囲の広い総称プロファイルがどのように定義されているかを効率的に調査できます。

---

**問題7：特定セグメント情報のみの表示**

ユーザー`BPXUSER`のプロファイルのうち、z/OS UNIXに関連する情報（UID、ホームディレクトリ、デフォルトシェルなど）だけを簡潔に確認したい。基本情報（`RACF INFORMATION`）は表示させずに、`OMVS`セグメントの情報のみを表示する場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**
```
LISTUSER BPXUSER OMVS NORACF
```

**【解説】**
`LISTUSER`コマンドでは、`OMVS`や`TSO`といったセグメント名を指定することで、表示する情報を特定のセグメントに限定できます。さらに`NORACF`オペランドを追加すると、デフォルトで表示される基本情報（`RACF INFORMATION`セクション）が出力されず、指定したセグメント情報のみが出力されるため、目的の情報を素早く確認できます。

---

**問題8：非アクティブなユーザーの棚卸し**

セキュリティ監査の一環として、90日以上システムに一度もログオンしていないユーザーをすべてリストアップしたい場合、どのようなコマンドを実行しますか？

<br>
<br>
<br>

**▼ 解答**

```
SEARCH CLASS(USER) WHEN(LOGON(DAYS(90)))
```

**【解説】**
`SEARCH`コマンドの`WHEN`オペランドは、時間に関連する条件での検索を可能にします。`WHEN(LOGON(DAYS(90)))`は、「最終ログオン日が90日以上前」という条件を指定しています。このコマンドにより、長期間利用されていないアカウントを特定することができます。


## 第7章：継続的なセキュリティ維持のための監査

これまでRACFによるアクセス制御の仕組み、すなわち「認証」と「認可」について解説してきました。しかし、堅牢なセキュリティを維持するためには、もう一つの重要な柱である「監査」が不可欠です。この章では、監査の重要性とその仕組みの概要に触れます。

### 7-1. なぜ監査が重要なのか

RACFにおける監査とは、**「誰が、いつ、何をした（しようとした）か」を記録し、追跡可能にすること**です。システムにとって以下のようなメリットがあります。

*   **不正アクセスの検知**: 許可されていないリソースへのアクセス試行が繰り返された場合、その記録から攻撃の兆候を早期に検知できます。
*   **コンプライアンス遵守**: 多くのセキュリティ基準や法規制では、アクセス記録の保持と定期的なレビューが義務付けられています。監査ログは、その要求に応えるための重要な証跡となります。
*   **インシデント追跡**: 万が一セキュリティインシデントが発生した際に、監査ログを分析することで、原因究明や影響範囲の特定を迅速に行うことができます。

設定したルールが正しく守られているか、あるいは破ろうとする者がいないかを監視する。それが監査の役割です。

### 7-2. 監査の仕組みとSMFレコード

RACFは、リソースへのアクセスイベント（成功・失敗の両方）をログとして記録する機能を備えています。このログは、z/OSのシステム活動記録機能である**SMF（System Management Facilities）**に、特定のレコードタイプとして書き込まれます。

つまり、RACFが行ったセキュリティ判断の結果は、すべてSMFデータセットという巨大なログファイルに集約されていく仕組みです。

本記事では詳細に立ち入りませんが、RACFにはこうした監査機能が備わっており、それがz/OSの高い信頼性を支える一因となっていることを覚えておきましょう。


## おわりに
本記事では、z/OSセキュリティの中核を担うRACFについて、その全体像から具体的なコマンド操作までを体系的に解説してきました。

まず、RACFが **「認証・認可・監査」** という3つの役割を担うことを学び、その管理体系が **「ユーザー」「グループ」「リソース」** という基本要素で構成されていることを理解しました。さらに、それらの知識を元に、**新規ユーザー追加やリソース保護といった具体的なシナリオを通じた一連の操作フロー**も紹介しました。

ここで解説したのは奥深いRACFの世界の入り口に過ぎません。さらに学習を深めたいと感じたのであれば、ご自身の環境で権限がどのように使われているかを調査してみることをお勧めします。本記事で得た基礎知識は、次のステップに進むための土台となるはずです。

この記事が、あなたのRACFに対する理解を深め、メインフレームエンジニアとしてのキャリアを歩む上での一助となれば幸いです。最後までお読みいただき、誠にありがとうございました。


### 参考文献
z/OS: z/OS Security Server RACF Auditor's Guide

https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/icha800_v3r1.pdf

z/OS: z/OS Security Server RACF Command Language Reference

https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/icha400_v3r1.pdf

z/OS: z/OS Security Server RACF General User's Guide

https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/icha100_v3r1.pdf

z/OS: z/OS Security Server RACF Security Administrator's Guide

https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/icha700_v3r1.pdf

Cybersecurity and Compliance

https://www.broadcom.com/products/mainframe/security

z/OSに対するセキュリティシステム監査（RACFとは？）｜inukiti

https://note.com/inukiti335/n/n9704d718c5ca

RACFユーザー登録

https://arteceed.squares.net/?p=462