|
|
日本−日本語 | |
|
|
 |
|
HP OpenVMS: システム・セキュリティ・ガイド > パート III システム管理者のためのセキュリティ
第8章 システムのデータと資源へのアクセスの制御 |
|
|
目次 この章では，ユーザ・グループを設計する方法と，作業の実行に必要な識別情報 (UIC，識別子，特権) をユーザに与える方法について説明します。 システムのデータと資源を適切に保護すると同時に，ユーザが効率的に作業できるよう，適切な保護コードと ACL をオブジェクトに割り当てる方法も示します。 この章では，読者が 第4章 「データの保護」と 第5章 「オブジェクト・クラスの詳細」の内容を習得していることを前提としています。 ユーザ・グループを設計する際には，セキュリティ管理者が作成するグループは，データと資源の保護に影響を与え，GROUP，GRPNAM，および GRPPRV 特権を受けるユーザに影響する点に留意してください。 ユーザの職務に応じてグループ分けする方法が考えられます。 会計，エンジニアリング，マーケティング，人事など共通の職務を行うユーザのグループを調べます。 また，組織における将来の計画を見越し， これらの考えを戦略に組み込みます。 グループの設計の微調整はいつでもできますが，ユーザの職務に応じた合理的なグループ分けを把握することが最も重要です。 UIC グループへのユーザの配置を決定するには，次の 2 つのガイドラインに従います。
ただし，UIC グループの設計には制約があります。 セキュリティ管理者が所有するファイルへのアクセス権を，UIC グループの少数のメンバにのみ与えることも，ワールド・アクセス権を付与することなく，セキュリティ管理者のファイルへのアクセス権を複数の UIC グループのメンバに付与することもできます。 これらの制約については， 8.1.2 項 「UIC グループの設計に関する制約」で説明しています。 架空の Rainbow Paint Company は，経営執行，会計，マーケティング，発送，管理の，5 つの部署がある流通企業です。 表 8-1 「部署と職務による従業員のグループ分け」 に，さまざまな部署における，コンピュータ資源を必要とする従業員を示します。 この表には，従業員が担当する職務の一覧も示します。 表 8-1 部署と職務による従業員のグループ分け
この会社が複数の部署に編成されていることは，同じ部署の人員は，多くの同じ職務を遂行することを意味します。 たとえば，この会社で経理作業を行う全従業員を，会計課にグループ分けする利点は，従業員の相互連絡と，共有しなければならないデータへのアクセスが簡単に行える点です。 Rainbow Paint のコンピュータ資源のシステム管理者である Olivia Westwood は，既存の組織構造に基づいて UIC グループを設定します。 たとえば，会計課の従業員 (Ruiz，Smith，Jacobs，Ross) を，UIC グループ ACCOUNTING のメンバにすることができます。 このように UIC グループを設定することで，ユーザ Ruiz は，ユーザ Smith などのデータに簡単にアクセスできるようになり，他のメンバについても同様です。 部署を効果的に組織化することにより，選ばれた従業員だけが会社内のすべてのデータと従業員にアクセスできるようになります。 たとえば，会計課の職務の 1 つに，給与計算があります。 給与計算の情報は機密情報であるため，発送とマーケティングの従業員は，その情報にアクセスすることは禁じられています。 Rainbow Paint のコンピュータ資源のシステム管理者として，Westwood は，ACCOUNTING，EXECUTIVE，MARKETING，SHIPPING，および ADMINISTRATION の UIC グループを設定します。 これらのグループは，会社の各々の部署に対応します。 同じ UIC グループのメンバには，次の例のように，ファイルへの共通のアクセス権を付与することができます。
このコマンドを使用して，ファイル GROUP_STATS.DAT の所有者は，UIC グループの各メンバに，ファイルに対する読み込みアクセス権，書き込みアクセス権，および実行アクセス権を許可します。 場合によって UIC ベースの保護が，オブジェクト保護のニーズに対する最適のソリューションではないことがあります。 複数の UIC グループのユーザが，システム上の共通ファイルなどの資源へのアクセス権を必要とする場合，UIC ベースの保護で利用できる方法は，そのオブジェクトに対するワールド・アクセス権を付与する方法か (全ユーザがそのオブジェクトにアクセスできる)，各ユーザの特権を拡張する方法のみです。 どちらの選択肢も望ましくありません。 また，UIC グループのユーザに複数のタイプのファイル・アクセス権を許可したり，同じグループ内の一部のユーザに対して，オブジェクトへのアクセス権を付与しない必要がある場合もあります。 このような場合も，UIC ベースの保護は，これらのニーズを満たす適切なソリューションではありません。 以降の節で説明するアクセス制御リスト (ACL) は，システム上のファイルなどのオブジェクトを保護する別の手段を提供します。 4.5 項 「保護コードによるアクセスの制御」「保護コードによるアクセスの制御」で説明しているように，サイトのセキュリティ管理者は，UIC のカテゴリの詳細を十分認識することが非常に重要になります。 特定の UIC グループにユーザを入れることで，そのユーザにシステム特権を付与できます。 また，システム特権を持つユーザは，システム上のすべての保護オブジェクトに対する制御アクセス権を持っています。 SYSPRV 特権は，デフォルトでは 10 以下のすべての UIC グループに付与されますが，システム UIC カテゴリの実際の範囲は，MAXSYSGROUP システム・パラメータの値によって決まります。 システム・ファイルを所有するグループに，GRPPRV 特権を持つユーザを入れると，セキュリティ上問題になる場合があります。 データと資源の保護の問題を解決するために，UIC グループを再構築するではなく，アクセス制御リスト (ACL) を使用して目的を達成できる場合があります。 ACL の詳細については， 4.4 項 「ACL によるアクセスの制御」「ACL によるアクセスの制御」で説明しています。 UIC は ACE において識別子として機能するため，簡単に ACL を作成して，さまざまな UIC グループの特定のユーザに，オブジェクトへのアクセスを許可することができます。 たとえば，Rainbow Paint Company の特定のユーザに，PAYROLL.DAT ファイルへのアクセスを許可する，次のような ACL を作成する場合を考えます。
多数のユーザが同じアクセス権を必要とする場合があります。 しかし，UIC 識別子のみで構成される ACL は，長くなりすぎることがあります。 ACL を短縮するために，システム定義の環境識別子を含めたり，汎用識別子を作成することができます ( 表 4-1 「主なライト識別子のタイプ」表 4‐1 を参照)。 汎用識別子を作成する際には，システムで必要な識別子の名前を考え，その識別子の保持者のセットを作成します。 続いて，識別子をライト・データベースに追加し，識別子を該当するユーザに割り当てます。 たとえば，Rainbow Paint Company で PAYROLL 識別子をライト・データベースに追加することにしたとします。 その識別子の保持者は，PAYROLL.DAT に対する読み込みアクセス権，書き込みアクセス権，実行アクセス権，および削除アクセス権を必要とする全ユーザで，OWESTWOOD，CRUIZ，および RSMITH です。 識別子とその保持者を定義したら，セキュリティ管理者は次の ACL を使用して，同じタイプのアクセス権を PAYROLL.DAT に指定します。
ACL と識別子の設計の最終ステップは，それぞれの識別子がいつどのように使用されるかを考慮することです。 ユーザは多くの場合，データベースの更新やシステム操作の実行など，さまざまな目的のために識別子を保持します。 このため，識別子の使用を限定したい場合があります。 識別子の使用を限定する方法はいくつかあります。 1 つは，環境識別子を使用する方法で，もう 1 つは 8.6.7 項 「識別子のカスタマイズ」で説明しているように，識別子に特別な属性を追加する方法です。 環境識別子は，ユーザがシステムに最初に入ったときの方法に応じた，さまざまなタイプのユーザを規定します。 ローカル，ダイアルアップ，リモート，会話型，ネットワーク，およびバッチのいずれかとなるこれらの識別子は，ユーザがシステムを使用する形態に応じて，大規模なユーザ・グループを定義することができます。 一般的にこれらのタイプの識別子は，ほかの識別子と組み合わせて使用します。 たとえば次の ACE は，ローカル・ターミナルからログインした場合にのみ，オブジェクトに対する読み込みアクセス権，書き込みアクセス権，実行アクセス権，および削除アクセス権をユーザ Martin に許可します。
ACL で環境識別子を使用して，特定のログインのクラス全体に対して，アクセスを拒否することができます。 たとえば，次の ACE はすべてのダイアルアップ・ユーザに対して，アクセスを拒否します。
DECwindows 環境のユーザにこれらの環境識別子を割り当てる際には，DECwindows プロセスは事実上任意のタイプのプロセスになりうる点に留意してください。 たとえば，ユーザはバッチ・ジョブの中で DECwindows Mail を実行できます。 プロセスが DECwindows ワークステーションを介してユーザと会話型の通信を行っている場合であっても，そのプロセスはバッチ・ジョブに分類されます。
識別子の定義の詳細については， 8.6 項 「ライト・データベースへの登録」と，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の AUTHORIZE の説明を参照してください。 ACL の作成と保守の詳細については， 第4章 「データの保護」を参照してください。 作業が多い場合は，アクセス制御リスト・エディタ (ACL エディタ) を使用するとよいでしょう。 ACL エディタについては，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』で説明しています。 システムで必要な識別子の名前を考え，識別子の保持者のセットを作成したら，AUTHORIZE を使用して識別子をライト・データベースに追加し，対象ユーザに識別子を割り当てます。 これらの関連付けは，ライト・データベース (RIGHTSLIST.DAT) に保持されます。 ライト・データベースは，ユーザと識別子の追加/削除を行うことで保守します。 ライト・データベースは，初めにシステムのインストール時に作成され，[SYSEXE] ディレクトリにあります。 作成時にライト・データベースには，環境識別子の名前が含まれています。 登録ファイルにユーザを追加すると，登録したユーザごとに 1 つの識別子が追加されます。 UIC 識別子と呼ばれるこの識別子は，ユーザの UIC およびユーザ名と関連付けられています。 ライト・データベースにも，各 UIC グループ名に相当する識別子があります。 新しい UIC グループの最初のメンバとして新規ユーザを追加し，そのユーザにアカウント・グループ名を指定すると，次の例のように，アカウント・グループ名に対応する識別子がライト・データベースに追加されます。
ROB のアカウントを追加する際にアカウント名 MGMT を指定していますが，その名前の UIC グループが存在しないため，ライト・データベースに MGMT 識別子が追加されます。 各サイトは，実際の使用状況と要件に従って，それぞれのライト・データベースを合わせていきます。 AUTHORIZE を使用してシステム・ユーザ登録ファイル (SYSUAF.DAT) のユーザ名の追加，削除または変更を行うと，ライト・リストが SYSUAF.DAT に対応するように，AUTHORIZE によって対応する変更が RIGHTSLIST.DAT に加えられます。 ライト・データベースの作成と保守は自動的に行われるため，AUTHORIZE の CREATE/RIGHTS コマンドは，ほとんど使用する必要がありません。 ただし，ライト・データベースが破損したり削除された場合は，このコマンドを使用して新しいライト・データベースを作成できます。 詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 定期的にライト・データベースを表示して，ライト・データベースが正確で，情報が最新であることを確認する必要があります。 このためには，2 つの AUTHORIZE の SHOW/IDENTIFIER コマンドと SHOW/RIGHTS コマンドを使用します。 ある識別子のすべての保持者を表示するには，次の例のように SHOW/IDENTIFIER コマンドを使用します。
システム上の全識別子の全保持者を表示するには，次のようにアスタリスク (*) ワールドカードを使用します。
特定のユーザが保持する識別子を表示するには，次のように SHOW/RIGHTS コマンドを使用します。
全ユーザが保持する全識別子を表示するには，次のようにアスタリスクのワイルドカードを使用します。
最初のコマンドにより，ユーザがアルファベット順で表示されます。 2 番目のコマンドでは，UIC 順にユーザが表示されます。 ライト・リストに識別子を追加するには，次のように AUTHORIZE の ADD/IDENTIFIER コマンドを使用します。
8.6.7 項 「識別子のカスタマイズ」 で説明している属性を使用してユーザに識別子を付与するには，識別子を追加する際にその属性を指定する必要があります。 たとえば，識別子の追加または変更をユーザに許可するには，Dynamic 属性を指定します。
誤ってライト・リストを削除してしまい，バックアップ・コピーからも復元できない場合は，次のように CREATE/RIGHTS コマンドを入力し，その後に ADD/IDENTIFIER コマンドを入力して，RIGHTSLIST.DAT を再度作成します。
ADD/IDENTIFIER コマンドは，ライト・リストに，SYSUAF.DAT の各ユーザ名に対応する UIC 識別子を作成します。 この作業を完了するには，ADD/IDENTIFIER コマンドを使用して，失われたすべての汎用識別子を追加します。 続いて， 8.6.4 項 「ユーザへの識別子の割り当て」で説明している方法で，GRANT/IDENTIFIER コマンドを使用して識別子の保持者を再定義します。 識別子を追加した後，次の例のように AUTHORIZE の GRANT/IDENTIFIER コマンドを使用して，既存の識別子の保持者としてユーザを関連付けます。
ユーザ Martin に，PAYROLL 識別子に加えて EXECUTIVE 識別子を付与するには，GRANT/IDENTIFIER コマンドを再度使用する必要があります。 GRANT/IDENTIFIER コマンドでは，一度に 1 つのみ保持者の関連付けを行うことができます。 上記のすべての例で，AUTHORIZE を使用して，ユーザ (具体的には Martin と Ippolito) に対応する UIC 識別子に PAYROLL 識別子を関連付けています。 識別子は両方ともライト・データベースに存在する必要があります。 ユーザが退職した場合は，そのユーザの UAF レコードを削除します。 そのユーザが代理アカウントにアクセスできるすべてのサイトの管理者に通知して，リモート・ノードの NETPROXY.DAT ファイルにある代理アクセス情報を削除してもらいます。 AUTHORIZE を実行してユーザの UAF レコードを削除すると，AUTHORIZE によって，ライト・データベースにある識別子の保持者としてのユーザの関連付けも削除されます。 ただし，退職したユーザが特定の識別子の唯一の保持者である場合は，今後の混乱を避けるために，その識別子を削除します。 ライト・データベースから識別子を削除する前には，次の操作を行います。
ACE に 16 進形式の識別子がある場合，それは汎用識別子がライト・データベースから削除されていることを示します。 同様に，識別子が数値形式の UIC として表示されている場合，元の識別子は UIC で，削除されていることを示します。 数値形式の UIC または 16 進形式の識別子を持つ ACE は削除します。 従業員の退職後には，UIC を再利用しないことをお勧めします。 新しい従業員が，数値形式の古い UIC を依然として参照している ACL エントリを通じて，前任の従業員のアクセス権の一部またはすべてを手に入れる場合があるためです。 識別子の名前を変更するには，次の形式で AUTHORIZE の RENAME/IDENTIFIER コマンドを使用します。 RENAME/IDENTIFIER old-identifier new-identifier 識別子の名前を変更しても，以前の識別子を通じて利用できた資源のセットは維持されます。 名前を変更した識別子が含まれる ACL は，自動的に新しい識別子名を表示します。 ライト・リストに識別子を追加する時，あるいは，ユーザに識別子を付与する時，その識別子に属性と呼ばれる特別な特性を持たせることができます。 使用可能な属性は数多くありますが，大半のサイトでは次の属性をよく使用します。
多くの場合，セキュリティ要件が高いサイトでは，以上の他に，ユーザによるライト・データベースの検索を防止する次の 2 つの属性を使用します。
RIGHTSLIST.DAT への読み取りアクセス権は，Holder Hidden 属性および Name Hidden 属性をオーバーライドします。 デフォルトでは，ライト・リストはワールド・ユーザにアクセス権を付与しません。 ライト・リストの保護は，"S:RWED,O;RWED,G:R,W:" となっています。 以降の節では各属性について解説し，どのような場合にサイトの識別子の一部に属性を追加する必要があるかを説明します。 ユーザに識別子を付与すると，そのユーザによって作成されるプロセスは，プロセスが存続し続ける間，識別子を保持します。 しかし，Dynamic 属性を指定した識別子を付与すると，その識別子を保持するユーザは，DCL の SET RIGHTS_LIST コマンドを使用して，必要に応じてプロセス・ライト・リストを対象に識別子またはその属性の追加/削除を行うことができます。 識別子の変更をユーザに許可するには，次の例のように AUTHORIZE を使用して，ライト・データベースに識別子を追加する際に Dynamic 属性を指定します。
識別子の特定の保持者に識別子の変更を許可するには，次のように，識別子を付与する際に Dynamic 属性を追加します。
以降，ユーザ Schwartz は，次のコマンドを使用してプロセス・ライト・リストから MGMT101 識別子を削除できます。
また，Dynamic 属性と Resource 属性を持つ識別子を保持するユーザは，SET RIGHTS_LIST コマンドを使用してその識別子の Resource 属性のみを削除できます。 識別子を削除することで，設定されているセキュリティ・ポリシーをユーザが回避できる場合があるため，Dynamic 属性を持つ識別子をユーザに付与する際には注意してください。 Dynamic 属性を持つ識別子を保持するユーザにアクセス権を付与しないために，ACL で識別子が使用されている場合，ユーザは，プロセス・ライト・リストから識別子を削除することで，別の ACL エントリを通じてオブジェクトへのアクセス権を取得できる場合があります。 セキュリティ要件が高いサイトでは，特定の識別子の保持者を隠して，侵入のターゲットとして望ましいアカウントを悪意のあるユーザが判定できないようにすることが可能です。 AUTHORIZE の MODIFY/IDENTIFIER コマンドを使用して，ユーザが保持する識別子に属性を適用します。 次に例を示します。
これで，詮索行為を行う人物は，秘密プロジェクトに関与している人物がわからなくなります。 セキュリティ要件が高いサイトでは，識別子の名前を隠すことができます。 たとえば，強制アクセス制御を実装するサイトでは，セキュリティ・カテゴリに関連付けられた識別子の名前を隠すことができます。 これにより，識別子を保持する本人でなければ，識別子の名前を表示できなくなります。 識別子に Name Hidden 属性が指定されている場合，要求側のプロセスがその識別子を保持している場合を除き，オペレーティング・システムは，バイナリ値から ASCII または ASCII からバイナリ値への識別子の変換を拒否します。 この属性を識別子に割り当てるには，次のように AUTHORIZE の MODIFY/IDENTIFIER コマンドを使用します。
No Access 属性は，識別子の保持をプロセスに許可しますが，オブジェクトへのアクセス権の判定において，その識別子を考慮しないようにします。 たとえば，Resource 属性と No Access 属性を持つユーザは，識別子にディスク領域を割り当てることができますが，その識別子が所有するオブジェクトにはアクセスできません。 また，システム管理者はデータを管理し，そのデータに関連する作業を実行できますが，ファイルの読み書きはできません。 セキュリティ管理者は，識別子によるファイル領域の所有，および識別子へのファイル領域の割り当てを許可する一方で，ファイル・アクセスを禁止することができます。 ライト・データベースに識別子を追加する際に，Resource 属性とともに No Access 属性を指定するには，次の例のように AUTHORIZE を使用します。
Resource 属性を持つ識別子を保持するユーザの権限を制限するには，次のように，対象の全ユーザに対して，Resource 属性のほかに No Access 属性も付属する識別子を付与します。
一般的にディスク領域の消費は，ファイル所有者のディスク制限からディスク領域を差し引くことにより，各ファイルの作成者に割り当てられます。 システム管理者とセキュリティ管理者は，個別ユーザではなく，(部署やプロジェクトなどの) ユーザの論理グループに従って，ディスク領域の使用状況を追跡することが望ましい場合があります。 このようなグループの指定には，汎用識別子を使用します。 したがって，汎用識別子がディレクトリを所有する場合，ディレクトリに作成されたファイルにより使用されるディスク領域は，ファイルの作成者の UIC ではなく，識別子に割り当てられる場合があります。 ファイル領域を識別子が所有するようにして，識別子への割り当てを可能にするには，次の例のように，ライト・データベースに識別子を追加する際に，AUTHORIZE を使用して Resource 属性を指定します。
識別子の特定の保持者に対して，識別子へのディスク領域の割り当てを許可するには，次の手順を実行します。
資源識別子 MGMT101 は，セキュリティ管理者がディレクトリ INVENTORY.DIR に作成するすべてのファイルを所有することになるため，セキュリティ管理者は ACE を使用して，与えられるファイル・アクセス権のタイプを指定します。 ファイルの作成者に付与されるアクセス権を設定するには，作成者 ACE (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) を含めます。 また，システムに ACE を割り当てさせることもできます。 システムの ACE はファイルの作成者に対して，制御アクセス権と，保護コードの所有者フィールドで指定されているアクセス権を付与します。 保護コードを設定するには，INVENTORY.DIR の ACE に，(DEFAULT_PROTECTION, ACCESS=O:RW) のように，デフォルトの保護用 ACE を含めます。 詳細については， 8.8.1.2 項 「資源識別子により所有されるディレクトリのデフォルトの設定」を参照してください。 識別子を保持する全ユーザが，その識別子と関連付けられた Resource 属性も保持するとは限りません。 ある識別子によって所有されているディレクトリにファイルを作成しても，その識別子の Resource 属性を持っていなければ，そのファイルはユーザの UIC により所有され，必要なディスク領域はユーザのディスク制限から差し引かれます。 Subsystem 属性を持つサブシステム識別子をユーザに付与することで，保護サブシステムを管理する権限をユーザに付与できます。 これによりユーザは，サブシステムによって管理されるオブジェクトにイメージがアクセスできるようにすることが可能になります。 保護サブシステムの説明については， 第14章 「保護サブシステムの使用」を参照してください。 次の例では，識別子 MAIL_SUBSYSTEM を使用して，ユーザ Schwartz にサブシステムを作成する権限を付与しています。 また Schwartz には，アクセス制御を設定するためのアプリケーション・イメージへの制御アクセス権も付与しています。
特権セキュリティ管理者は，SET RIGHTS_LIST コマンドを使用して，システム上の任意のプロセスのライト・リストを変更したり，システム・ライト・リストの識別子を変更できます。 システム・ライト・リストに識別子を追加すると，その識別子を全ユーザに付与することになります。 また，SET RIGHTS_LIST コマンドを使用して，既存の識別子に属性を追加することもできます。 システム・ライト・リストの使用法の 1 つに，サイト固有の環境条件の有効化があります。 たとえば，午前 8 時に実行するスケジュールが組まれているバッチ・ジョブは，次の識別子を追加することができます。
午後 5 時に実行するスケジュールが組まれている別のバッチ・ジョブは，次のように，識別子 DAY_SHIFT を削除することができます。
結果的に，識別子 DAY_SHIFT を持つ保護オブジェクトへのアクセスが，午前 8 時から午後 5 時まで有効になります。 次の例のコマンドは，プロセス DEDNAM のライト・リストに SALES 識別子を追加することで，プロセス・ライト・リストを変更しています。 Resource 属性を指定することで，SALES 識別子の保持者に，その識別子へのディスク領域の割り当てを可能にしています。
一部のシステム処理は，特定の特権を有するユーザに制限されます。 このような制限により，オペレーティング・システムの性能の一貫性が守られる結果，ユーザに提供されるサービスの一貫性も保たれます。 各ユーザへの特権の付与は，(a) 特権に対する正当なニーズがユーザにあるかどうか，(b) システムを妨害することなく特権を使用するスキルと経験をユーザが持っているかどうか，という 2 つの要素に基づいて判断します。 ユーザの特権は，そのユーザの UAF レコードに，2 つの特権ベクタとして記録されます。 一方のベクタには許可された特権が格納され，もう一方のベクタにはデフォルトの特権が格納されます。 デフォルトの特権は，ログイン時にユーザ・プロセスが獲得する，許可された特権のサブセットです。 ユーザがシステムにログインすると，ユーザの特権ベクタが，ユーザのプロセスのヘッダに保存されます。 このようにして，そのユーザの特権は，ユーザに対して作成されるプロセスに渡されます。 ユーザは，DCL の SET PROCESS/PRIVILEGES コマンドを使用して，ユーザに許可される特権を有効/無効にすることができます。 オペレーティング・システムは，特権の使用状況を監視および監査します。 特定の特権に対する監査を有効にし，監査ログ・ファイルを調べることで，DCL コマンドまたはシステム・サービスの実行にどの特権が使用されたかを確認できます。 詳細については， 第10章 「セキュリティ監査の実施」を参照してください。 特権を有するユーザがシステムにもたらす可能性のある損害に従って，特権は次の 7 つのカテゴリに分けられています。
表 8-2 「OpenVMS の特権」 に，特権の分類と，各特権に関連付けられている能力の簡単な定義を示します。 表 8-2 OpenVMS の特権
付録 A 「特権の割り当て」 に，すべてのユーザ特権と，ユーザ特権を付与すべき条件に関する推奨事項を示します。 ユーザ特権を割り当てる際には，慎重に行います。 表 8-3 「システム・ユーザの最低限の特権」 の要約ガイドラインは，システム・ユーザの一般的なクラスに対する最低限の特権の要件です。 表 8-3 システム・ユーザの最低限の特権
特権を付与すると，セキュリティ管理者が特権を削除するまで，ユーザに特権が認められます。 このような全面的な許可を避けるには，必要に応じて特権を付与するようにします。 たとえば一部のユーザが，強力な特権のいずれかを必要とするプログラムを実行しなければならない場合があります。 その場合には，インストール・ユーティリティ (INSTALL) を使用して，必要な特権を与えてプログラムをインストールします。 8.7.4 項 「特権イメージのインストール」で，特権イメージのインストールを詳細に説明しています。 全面的な特権の付与に代わる方法としては，緊急または専用の特権アカウントを設定する方法があります。 ユーザは，特定の機能を実行するためにのみ，このような特権アカウントにログインします。 この方法には，次の 2 つの選択肢があります。
どちらの方法でも，長いパスワード，短いパスワード有効期間，時間帯の制限，操作モードの制限 (ダイアルアップ，ネットワーク，リモート，またはバッチ・ログインは不可) など，特権アカウントに特別な制限を設定できます。 また，アカウントの有効期間を短くすれば，特権の要件を頻繁に検討するように求められます。 もう 1 つの方法として， 第14章 「保護サブシステムの使用」で説明している保護サブシステムを使用して，システム特権の必要性をなくすという方法もあります。 必要な特権を有する既知イメージとしてイメージをインストールしない限り，ユーザは，そのユーザが所有していない特権を必要とするイメージは実行できません。 既知イメージのインストール方法については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 特権を有する既知イメージを実行すると，イメージを実行している間，イメージを実行しているユーザ・プロセスに特権が付与されます。 したがって，(HP が提供する通常の設定以外の) 強力な特権を有するイメージは，イメージの機能により特権が必要であり，イメージが安全に機能することが確認された後にのみインストールします。 また，イメージへのアクセス権を，一部のユーザに制限することも検討してください。 特権を使用してインストールされたイメージは，強力な特権がすべて有効になった状態で起動されます。 安全性を最大限にするため，強力な特権を使用して実行するよう設計されたイメージは，$SETPRV システム・サービスを使用して，すべての強力な特権を起動直後に無効にし，必要な場合にのみ有効化するべきです。 特権を有するイメージのインストールの例を次に示します。 System Dump Analyzer (SDA) ユーティリティは，実行中のシステムを分析するために CMKRNL 特権が必要です。
ユーザのグループと識別子を設計したら，どの保護オブジェクトに対するアクセス許可をユーザが必要とし，どの保護オブジェクトの制限を解除できるかを検討する必要があります。 第5章 「オブジェクト・クラスの詳細」に示す新しいオブジェクトのデフォルトの保護を十分に把握し，必要な場合は，以降の節で説明する手順でデフォルトを変更します。 オブジェクトの保護と所有権のデフォルトを設定する手順は，オブジェクトがファイルであるか，別のクラスの保護オブジェクトであるかに応じて異なります。 5.4.5 項 「プロファイルの割り当て」「プロファイルの割り当て」で説明しているように，ユーザに影響を与える保護のデフォルトを指定できる領域は，4 つ存在します。 影響が大きい順に，次のとおりです。
また，DCL の SET VOLUME/PROTECTION コマンドによってボリュームに課せられる保護も考慮します。 この保護コードが指定されている場合は，ディレクトリおよびファイルに対する保護コードに関係なく，ボリュームのあらゆる部分への該当ユーザによるアクセスが禁止されます。 SET VOLUME コマンドを使用してボリューム保護を指定していない場合，該当ボリュームには全ユーザがアクセスできます。 ファイル所有権の割り当ては，保護チェックの結果に影響します。 この組み合わせによる保護構造の運用上の効果を， 図 8-1 「ファイル作成のフローチャート」， 図 8-2 「ファイル作成のフローチャート」，および 図 8-3 「ファイル作成のフローチャート」 に示します。 デフォルトの動作を制御するために調整を行うことができます。 システム・パラメータ RMS_FILE PROT により指定されるシステム全体のデフォルトの保護コードにより，ユーザのデフォルトの保護は次のように設定されます。 (S:RWED,O:RWED,G:RE,W) ボリューム保護が，オペレータにより次のように設定されたとします。 (S:RWED,O:RWED,G:R,W) ディレクトリ [PROJECT] に対するファイル保護が，次のように設定されています。 (S:RWED,O:RW,G:R,W) サブディレクトリ [PROJECT.DIARY] に作成された全ファイルに高度な保護が必要である場合は，セキュリティ管理者，またはディレクトリへの制御アクセス権を持つ任意のユーザは，次のように，デフォルトの保護用 ACE で構成される ACL を持つこの特定のディレクトリに対して，特別なデフォルトの保護コードを定義できます。 (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) 次の DCL コマンドによって，必要なデフォルトの保護を実現できます。
この ACE がディレクトリ・ファイルに適用されると，そのディレクトリで作成または変更されるファイルは，デフォルトの保護コードの対象になります。 これらの保護コードはデフォルトにすぎないため，ディレクトリ内のファイルへの制御アクセス権を持つユーザは，次の DCL コマンドを使用することで，ファイルのデフォルト値の置き換えとして，固有の保護コードを含めることができます。 デフォルトの保護コードを置き換えると，新しいコードがデフォルトとなり，それ以降のバージョンのファイルに反映されます。 一部のユーザに特別なログイン・コマンド・プロシージャを用意する場合，対象グループのユーザに対して，システム・パラメータ RMS_FILEPROT により指定されるシステム全体のデフォルトのプロセス保護を追加することができます。 デフォルトのプロセス保護を指定するには，次のように，ログイン・コマンド・プロシージャに SET PROTECTION/DEFAULT コマンドを追加します。
ユーザのディレクトリに作成されたファイルは，明示的にオーバーライドする場合を除き，このデフォルトの保護コードが適用されます。 より柔軟性の高いデータ管理と，より正確なディスク使用量の会計管理を実現するために，資源識別子に所有されるディレクトリを設定し，ACL を使用して，ディレクトリとディレクトリ内で作成されるファイルへのアクセス権を制御することができます。 ACL は，プロジェクト識別子を保持するすべてのプロジェクトのメンバに対して，ファイル・アクセスを制限できます。 このようなアクセス制限を実現するには，識別子用 ACE を追加して，ファイルへのグループのアクセス権を定義します。 追加される 2 つ目の識別子用 ACE は，最初の識別子用 ACE の複製ですが，Default 属性を保持しています。 この Default 属性によって，ディレクトリ内で作成される全ファイルに，その ACE がコピーされることが保証されます。 ディレクトリのデフォルトの保護コードによっては，3 つ目の ACE であるデフォルトの保護用 ACE が必要になる場合があります。 デフォルトの保護用 ACE は，ディレクトリのファイルに対する保護コードを設定します。 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」「システムによる保護オブジェクトへのユーザのアクセス可否の判定」の説明にあるように，ACL によってファイルへのアクセスが禁止されている場合であっても，保護コードを通してアクセス権を得ることが可能です。 ACL は，ファイルへのグループのアクセスを制限するだけでなく，共通ディレクトリ内にユーザが作成したファイルに対するユーザのアクセス権のタイプを制御できます。 ファイルは資源識別子のディレクトリに作成されるため，資源識別子がそのファイルを所有します。 ユーザが作成したファイルにユーザ自身がアクセスするために，オペレーティング・システムは通常，ファイルの作成者に対して制御アクセス権を付与するだけでなく，保護コードの所有者フィールドで指定されているアクセス権も付与します。 ただし，ディレクトリの ACL に作成者 ACE を追加することで，この動作を変更できます。 作成者 ACE は，ユーザがプロジェクトのディレクトリに作成したファイルに対してユーザが保持するアクセス権のタイプを定義します。 セキュリティ管理者が，次のコマンド・シーケンスを使用してプロジェクト識別子 PROJECTX を設定し，それをプロジェクトのメンバに付与したとします。 プロジェクト識別子を，資源識別子を持っているライト・データベースに追加しているほか，資源識別子を持つユーザにも付与しています。 プロジェクト識別子は，ディスク領域を所有できるように，Resource 属性を持つ必要があります。
プロジェクトや部署に固有の識別子がディレクトリの所有者である場合，そのディレクトリに作成されるファイルによって使用される領域は，ファイルを作成した個人ではなく，適切な部署やプロジェクトに割り当てることができます。 ユーザが複数のプロジェクトに関わっている場合は，ユーザの個人用アカウントではなく，該当するプロジェクトにディスク領域の要件を割り当てることができます。 資源識別子が保有するディレクトリを設定する際には，まずプロジェクト識別子に許可されるディスク制限を作成します。 たとえば，次のコマンドはシステム管理ユーティリティ (SYSMAN) を起動し，超過値を 200 ブロックとして，識別子 PROJECTX に 2000 ブロックのディスク制限を割り当てています。
ディスク制限を設定したら，プロジェクト・ディレクトリを作成します。 たとえば，次の DCL コマンドでは，プロジェクト・ディレクトリ [PROJECTX] を作成し，その所有者として識別子 PROJECTX を設定しています。
ディレクトリ [PROJECTX] を設定する際には，ACL を使用して，プロジェクトのメンバにファイル・アクセス権を付与します。 次の例に，複数の ACE を使用してアクセス権を定義する方法を示します。
したがって，プロジェクトのメンバ Ross が [PROJECTX] ディレクトリにファイル SEPTEMBER-REPORTS.TXT を作成すると，ファイルには次のセキュリティ・プロファイルが与えられます。
プロジェクトのメンバは，ほかのユーザにより作成されたファイルを削除 (または制御) することは許可されていませんが，作成者 ACE によって，ユーザ自身が作成したファイルの削除アクセス権がユーザに与えられます。 作成者 ACE がない場合，プロジェクトの各メンバは，自分がディレクトリに作成したファイルへの完全なアクセス権を持っています。 たとえば Ross には，プロジェクトのディレクトリに作成されたファイルへの，次のアクセス権が与えられます。
ファイルと擬似ターミナル (FT) デバイスを除き，保護オブジェクトの全クラスに，新しいオブジェクトに対するセキュリティ要素を提供する 1 つ以上のテンプレート・プロファイルが用意されています。 したがって，1 つのメカニズムで，オブジェクトに関するデフォルトの保護コード，ACL，および所有権の要素を設定することができます。 あるシステム・スタートアップから次のシステム・スタートアップに移っても，これらの値が使用できるように，オペレーティング・システムは常にこれらの値を保存します。 SHOW SECURITY コマンドを使用して，自分のサイトの現在のデフォルト値を表示できます。 オペレーティング・システムのデフォルト値の一覧については， 第5章 「オブジェクト・クラスの詳細」を参照してください。 オペレーティング・システムは，セキュリティ・クラス・オブジェクトにより保存されたデータから，新しいオブジェクトのセキュリティ・プロファイルを作成します。 これらのオブジェクトはすべて論理構造であり，有効なアクセス・タイプ，テンプレート，および有効になっている監査のタイプなどのクラス要素を追跡するために使用されます。 図 8-4 「セキュリティ・クラス・オブジェクト」 に示すように，保護オブジェクトの各クラスは，セキュリティ・クラスのメンバを持っています。 独自の規則が適用されるメンバであるファイルを除き，すべてのメンバには，セキュリティ・プロファイル・テンプレートがあります。 クラス・テンプレートを表示するには，SHOW SECURITY/CLASS=SECURITY_CLASS コマンドを使用します。 たとえば次のコマンドは，論理名テーブルに使用できるテンプレートを表示します。 論理名テーブル・オブジェクトには，次の 3 つのテンプレートがあります。
セキュリティ・クラスのオブジェクトはすべて，他のオブジェクトと同じ方法で保護されます。 このため，SHOW SECURITY によるセキュリティ・クラス・オブジェクトの表示は，そのオブジェクト自身のセキュリティ・プロファイルから始まります。 次の表示は，セキュリティ・クラスにおける論理名テーブル・オブジェクトのプロファイルを示しています。 オブジェクトはシステムに所有され，その保護コードにより，すべてのユーザ・カテゴリに読み込みアクセス権が許可されていますが，書き込みアクセス権が許可されているのはシステムと所有者のカテゴリのみです。
セキュリティ管理者と，セキュリティ・クラス・オブジェクトに対する制御アクセス権を持つユーザは，次のコマンドを使用して，指定されたテンプレートの要素を変更することができます。 SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name 次のコマンドは，デバイス・クラスの MAILBOX テンプレートを変更します。 テンプレートの値を，S:RWPL,O:RWPL,G:RWPL,W:RWPL の保護から，グループ・アクセスとワールド・アクセスを許可しない保護に変更します。
オペレーティング・システムは，この値をすべての新しいメールボックスに適用します。 既存の各メールボックスの保護を変更するには，既存の各メールボックスに対して，明示的な SET SECURITY コマンドを入力します。 次に例を示します。
オペレーティング・システムは，セキュリティ・テンプレートに指定されているデフォルトのオブジェクト保護を保存するため，システムをリブートすると，リブート後に作成される全オブジェクトが，新しいデフォルトの保護で作成されるようになります。
DCL の SHOW SECURITY コマンドを使用すると，サイトの値を持つ使用可能なテンプレートがすべて表示されます。 第5章 「オブジェクト・クラスの詳細」に，デフォルトのシステム値の一覧があります。 この節では，ユーザが使用できるデータと資源を制限する，追加の方法を説明します。 新しいソフトウェアをインストールする際には，セキュリティに関するいくつかの点について対策を講じる必要があります。 通常のセキュリティ上の安全対策を何らかの方法で損なったり，弱体化させるソフトウェアのインストールを認めないようにする必要があります。 また，インストールするソフトウェアに特権を与えるべきかどうかも考慮する必要があります。 この節では，新しいソフトウェアをインストールするときのセキュリティの側面を説明します。 新しいソフトウェアには，システムに対する潜在的な危険のあるプログラムが含まれている可能性があります。 トロイの木馬プログラムと呼ばれるこれらのプログラムは，損害を与えることを目的として作成されており，多くの場合，次の動作を行う機能が含まれています。
このタイプの侵入からシステムを守るには，必ず信頼できる販売元からソフトウェアを購入します。 新しいユーザのトレーニングの際には，出所が定かでないソフトウェアの使用を避けることの重要性を強調します。 プログラムとディレクトリに対するもう 1 つの危険は，ウイルスと呼ばれるプログラムです。 トロイの木馬のソフトウェアは，悪意のないユーザがトロイの木馬とは知らずにそのソフトウェアを使用することを利用するのに対して，ウイルスはユーザの協力を必要としません。 ウイルスはファイル保護の欠陥を利用するプログラムで，システムに侵入し，コマンド・プロシージャと実行可能プログラムに変更を加えます。 コマンド・プロシージャに変更を加えることで，ユーザのアクセス権と特権を利用して増殖できるようになります。 ウイルスは，パーソナル・コンピュータの環境と比較すると，OpenVMS 環境ではあまり大きな問題にはなりません。 OpenVMS の保護機能と，環境の規模の大きさと多様性により，ウイルス攻撃が困難になっているためです。 しかし，ソフトウェアとデータの共有が可能な環境の中で，ウイルス攻撃から安全な環境は存在しません。 このタイプのセキュリティ侵害の主なターゲットは，ユーザのログイン・コマンド・プロシージャです。 一般的にログイン・コマンド・プロシージャには，定期的に実行され，簡単に変更が可能な DCL コマンドが含まれています。 ACL もターゲットになります。 ユーザがアクセス特権を共有する設計になっているファイル保護では，このタイプのプログラムが，多数のユーザのプログラムを介して実行され，その過程で新しい特権が獲得される可能性があります。 このタイプのセキュリティ侵害からシステムを保護するには，ファイル保護を適切に設計することが非常に重要です。 ターゲットになりやすいオブジェクトは，ユーザが変更できないようにします。 たとえば，ログイン・コマンド・プロシージャが許可するのは，最大でもほかのユーザへの読み取りアクセス権までとなるようにファイル保護を設定します。 また，ログイン・コマンド・プロシージャが含まれているディレクトリに対する書き込みアクセス権は，システム・カテゴリと所有者カテゴリのユーザにのみ許可するようにします。 損害の多くは，このようなプログラムが特権を持つターゲットのアカウントに到達すると発生するため，特権を持つユーザは，特にルート・ディレクトリ，実行可能ファイル，およびコマンド・プロシージャを慎重に保護する必要があります。 トロイの木馬の攻撃を抑止するには，ユーザは，コマンド・プロシージャやイメージのソースを調べずに，特権アカウントでコマンド・プロシージャやイメージを実行するべきではありません。 アプリケーション・イメージは，バイナリ・イメージが対応するソースを確実に反映するように，ソースからリビルドするべきです。 一部のソフトウェアは，実行に特権が必要です。 ソフトウェアを実行する必要があると想定される全ユーザに対して特権を拡張したり，必要な特権を与えてプログラムをインストールすることができます。 特権付きのソフトウェアをインストールすると，ユーザ個人が必要な特権を所有しているかどうかに関係なく，ユーザにソフトウェアの実行を許可することになります。 結果として，プロセスがソフトウェアを実行する間，プロセスの特権が拡張されます。 この方法にはいくつかのメリットがありますが，セキュリティに関わる危険性もあります。 8.7 項 「ユーザへの特権の付与」では，これらの選択肢についてさらに詳しく説明しています。 最も開放的なシステムであっても，システム・ソフトウェアの保護は必要です。 通常，HP は適切な UIC 保護を設定した状態で，システム・プログラムおよびデータベースを出荷しています。 しかし，何らかの理由でデフォルトの保護が不十分である場合，必要な SYSPRV 特権を持っていれば， 第4章 「データの保護」で概要を説明したテクニックを使用して，デフォルトの保護を変更できます。 また，追加の保護が必要であると判断されるファイルには，ACL も追加できます。 OpenVMS のインストール中に次の DCL コマンドを使用することで，システム管理者のアカウントから，システム・ファイルの完全なリストを取得できます。
このようなリストを作成し，参照用に保存しておくことをお勧めします。 定期的にこれらの値を現在のシステム・ファイルの保護と比較して，改ざんがないことを確認します。 DCL の DIRECTORY/SECURITY/OUTPUT コマンドと DIFFERENCES を使用すると，このようなチェックが簡単に行えます。 Alpha システムでは，読み取り専用の CD 配布メディアから，システム・ファイルとその保護のリストを入手できます。 OpenVMS ソフトウェアでは，インストールが正常に行われれば，この保護コードのセットが得られるはずです。 VAX システムでのシステム・ファイルとその保護のリストについては， 付録 B 「OpenVMS システム・ファイルの保護」 を参照してください。 OpenVMS ソフトウェアでは，インストールが正常に行われれば，この保護コードのセットが得られるはずです。 表 8-4 「ファイル保護に使用する DCL コマンド」 に，ファイル保護の設定と表示に使用する DCL コマンドの要約を示します。 これらのコマンドについては，『OpenVMS DCL ディクショナリ』で説明しています。 表 8-4 ファイル保護に使用する DCL コマンド
OpenVMS のインストール手順では，当初特権を与えずに MAIL.EXE をインストールします (MAIL.EXE は，その機能の実行に特権が必要ないためです)。 OpenVMS オペレーティング・システムの以前のバージョンには，MAIL.EXE の再インストール時にシステム管理者が割り当てることのある一部の特権を MAIL.EXE がチェック，無視，付与，またはオーバーライドできるようにするメカニズムが含まれていました。 これらの規制メカニズムは，予期しない状態や望ましくない状態を生み出すことがあったため，削除されました。
すでに述べたように，HP はシステム・プログラムにデフォルトの保護を提供しています。 しかし，特別な必要がある場合は，要件を満たすために ACL の能力を検討します。 たとえば，ACL を使用して，コンパイラなどのシステム・プログラムの使用を制限できます。 このような措置が必要になる要因として，パフォーマンスからライセンスの問題に至るまで，さまざまな要因が考えられます。 一部またはすべてのユーザがメディアを初期化できると不適切なケースがあるかどうかを考慮する必要もあります。 そのようなケースがある場合は，システム・プログラム SYS$SYSTEM:INIT.EXE に対して ACL を適用できます。 UIC ベースの保護コードにおいて，ワールド・カテゴリにアクセス権を付与しないようにします。 その後，ファイルを対象に，特定のユーザにアクセス権を付与する ACL を作成します。 同様に，会社の特定の部署がソフトウェア製品に対してライセンス料を支払った場合は，その部署に限定してソフトウェアを使用可能にして，他の部署には使用できないようにすることができます。 ワールド・カテゴリに，標準の UIC ベースの保護コードによってアクセス権が付与されていないことを確認し，ファイルの ACL に部署の識別子を介してアクセスを許可するエントリを作成します。 ACL 保護は，一部のユーザや保護サブシステムにアクセス権を限定するなど，アプリケーション・データベースの保護にも必要な場合があります。 ユーザによる DCL コマンドの使用を制御するには，いくつかの方法があります。 たとえば，以下の方法があります。
ディスク・スキャベンジングとは，パージまたは削除操作に続いて行われるファイル・ヘッダの削除の後で，データの磁気的な痕跡を読み取る処理です。 ユーザがシステムからファイルを削除すると，ファイル・ヘッダのみが削除されます。 データが上書きされるまで，そのデータはディスク・スキャベンジングのターゲットになる可能性があります。 セキュリティの要件が中または高であるサイトは，この行為を考慮する必要があります。 全体のセキュリティ機能を確立した後，UIC ベースのボリューム保護を使用することで，重要な情報が格納されているディスクへのアクセスを制限します。 ディスク・スキャベンジングはしばしば権限を持つユーザによって実行されるため，次の各節で説明する除去パターンとハイウォータ・マーク処理の実装を検討します。 ディスク除去の実装には，いくつかの方法があります。
セキュリティ要件のレベルが高いサイトでは，固定パターンよりもランダム・パターンの方が適しています。 わずかに残る磁気の痕跡を検出して使用する技術が，すでに利用できるようになっているためです。 そのため，ディスクが取り外され，このような特別な分析装置を使用して読み取られる危険性が十分あると結論付けられる場合は，除去パターンを複数回再書き込まなければならない場合があります。 データ・セキュリティ除去パターンをニーズに合うようカスタマイズする方法については，SYS$EXAMPLES:DOD_ERAPAT.MAR ファイルに記載されている情報から学習できます。 除去パターンは，セキュリティ要件が最も厳しいディスクにのみ使用します。 除去は時間を要し，システムのパフォーマンスに影響するためです。 ハイウォータ・マーク処理とは，各ファイルが書き込まれた位置の上限を追跡し，ユーザがその地点を超えてデータを読み取ろうとするのを禁止するテクニックを指します。 オペレーティング・システムは，さまざまなテキスト・エディタ，コンパイラ，およびリンカから出力されるファイル (つまり，プロセスが書き込む大部分のファイル) のセットをはじめとするすべての順編成，排他的アクセス・ファイルに対し，真のハイウォータ・マーク処理を実装します。 ファイル・ヘッダにあるハイウォータ・マークは，ファイルの論理的な終端マークが更新された時点 (通常はファイルが閉じられる時点) で更新されます。 共有ファイル (索引編成と順編成の両方) では，オペレーティング・システムは割り当て時除去の原則を使用して，真のハイウォータ・マーク処理に近い結果を実現します。 ファイルが作成または拡張されようとする時点で，システムはどれだけのディスク領域 (ファイルの範囲) が必要であるかを判断し，書き込み用に割り当てられる領域 (範囲) に，ゼロのセキュリティ除去パターンを適用します。 その後，ファイルは，そのファイルのために除去された領域に書き込まれます。 したがって，ユーザが (範囲全体を含め) 該当ファイルへのアクセス権を取得し，ファイルが書き込まれた領域を超える領域を読み込もうとしても，読み込めるのはデータ・セキュリティ除去パターンのみです。 デフォルトでは，オペレーティング・システムはすべてのボリュームに対してハイウォータ・マーク処理を有効にします。 ハイウォータ・マーク処理 は，ディスク・スキャベンジングの試みに対する抑止力になります。 ただし，ハイウォータ・マーク処理は余分に入出力が必要となるため，システム・パフォーマンスに影響を与えます。 DCL の SET VOLUME/NOHIGHWATER_MARKING コマンドを指定することで，ボリュームごとにハイウォータ・マーク処理と割り当て時除去を無効にすることができます。 ファイル，ディレクトリ，およびディスクのコピーを作成することで，データを喪失や破損から守ることができます。 問題が発生した場合は，バックアップ・コピーを復元して，作業を継続することができます。 メディアの安全な保管と，メディアへのアクセスの管理は，このプロセスの重要な要素です。 バックアップ・メディアは，対象サイト以外の場所に保管するのが理想的です。 効果的なバックアップ・スケジュールを立てることが，データの保護にとって非常に重要です。 バックアップを定期的に行うことで，ファイルの誤削除や破損による喪失を防ぐことができます。 バックアップの実施とバックアップ・スケジュールの設定の詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 バックアップ・ユーティリティ (BACKUP) ユーティリティは，セキュリティ・ポリシーを実装しないことに注意してください。 セキュリティ管理者がバックアップ・ユーティリティに明示的に指示する必要があります。 バックアップ・ユーティリティは，オペレータのセキュリティ・プロファイルを使用して実行されます。 多くの場合，そのセキュリティ・プロファイルは特権付きです。 バックアップ・セーブ・セットへのアクセスの制限は，システム・セキュリティの重要な要素です。 ファイル・システムは，バックアップ・セーブ・セットがディスクまたは磁気テープのどちらに保存されていても，バックアップ・セーブ・セットを単一のファイルとして扱います。 したがって，セーブ・セットにアクセスできるユーザであれば誰でもセーブ・セットの任意のファイルを読み込むことができます。 BACKUP は，個別ファイルの保護をチェックしません。 システム・セキュリティを維持するには，セーブ・セットを適切に保護することが非常に重要になります。 出力セーブ・セット修飾子の /BY_OWNER および /PROTECTION を使用して，ディスク上のセーブ・セットと，磁気テープ・ボリュームに，制限付きの保護を割り当てます。 保護が十分であれば，非特権ユーザがセーブ・セット・ボリュームをマウントしたり，セーブ・セットからファイルを読み込むことを防止できます。 施錠されたキャビネットにバックアップ・メディアを保管することで，オフ・ラインで保管されるセーブ・セットについても，物理的なセキュリティ対策を講じる必要があります。 セーブ・セットを Files--11 ディスクや順編成ディスクに書き込み，/PROTECTION 修飾子は指定しない場合，BACKUP は，セーブ・セットにデフォルトのプロセス保護を適用します。 /PROTECTION を指定した場合，未指定の保護カテゴリのデフォルトは，すべてデフォルトのプロセス保護になります。 保護情報は，磁気テープのボリューム・ヘッダ・レコードに書き込まれ，そのテープに保存されるすべてのセーブ・セットに適用されます。 そのため，出力セーブ・セット修飾子 /BY_OWNER および /PROTECTION が磁気テープ・セーブ・セットで有効であるのは，出力セーブ・セット修飾子 /REWIND を指定した場合のみです。 この修飾子によりテープは，先頭への巻き戻し，ボリューム・ヘッダ・レコードへの保護データの書き込み，テープの初期化を行うことができます。 /PROTECTION を指定した場合は，未指定の保護カテゴリのデフォルトは，すべてデフォルトのプロセス保護になります。 /PROTECTION および /BY_OWNER 修飾子と合わせて /REWIND を指定しなかった場合，磁気テープは既存の保護を保持します。 ただし，/REWIND のみを指定すると，保護がまったくない磁気テープになってしまいます。 次の例に，ディレクトリをテープにバックアップする方法を示します。
セーブ・セットにアクセスできるユーザであれば誰でもセーブ・セットの任意のファイルを読み込むことができます。 バックアップ・メディアのコピーをユーザには絶対に渡さないでください。 悪意のあるユーザがテープやディスクからファイルを復元し，システムのセキュリティを危険にさらす可能性があるためです。 非特権ユーザが特定のファイルを復元する必要がある場合も，セーブ・セットが格納されているボリュームを貸さないでください。 ボリューム上の全ファイルへのアクセス権を渡してしまう可能性があるためです。 特定のファイルを復元する最も安全な方法は，次の例のように，個別にファイルを復元する方法です。
選択されたファイルは，元のディレクトリ，所有権，および保護とともに復元されます。 この方法では，ファイル・システムによって，ユーザにファイル・アクセスが許可されているかどうかが判定されます。 以降の節では，ターミナルの使用制限に利用できる制御を説明します。 オペレーティング・システムは，デバイス・オブジェクト・クラス・テンプレート TERMINAL を使用して，SYSTEM アカウントのみがアクセスできるようにターミナルを設定します。 ユーザがログインすると，オペレーティング・システムは，所有権をシステム UIC から現在のプロセスの UIC に移します。 特定のターミナルへのログインを制限するには，次の方法があります。
システム・パスワードを適用することで，対象ターミナルの使用がシステム・パスワードを知っているユーザに限定されます。 ターミナルを，アプリケーション・ターミナルとして一部のユーザがアクセスできるようにするには，対象デバイスのセキュリティ特性の一部または全部を変更します。 (適切な保護コードを持つ) 特定のターミナルを対象に，コマンド・プロシージャ SYS$MANAGER:SYSTARTUP_VMS.COM に，DCL の SET SECURITY/CLASS=DEVICE コマンドを含めることができます。 この DCL コマンドは，ファイル構造ではないすべてのデバイスへのアクセスを制限できます。 また，デバイスに ACL を適用して，ユーザ・アクセスを制限することもできます。 モデム用のターミナル回線を設定する場合，会話型の使用が想定されているモデム装置が接続されている回線では，/COMMSYNC 修飾子を，DCL の SET TERMINAL コマンド (または TTDRIVER インタフェースの TT$M_COMMSYNC 属性) に対して絶対に設定しないでください。 この修飾子は，モデム電話回線に障害が発生した場合にターミナル回線からユーザ・プロセスを切断する，モデム・ターミナル属性を無効にします。 /COMMSYNCH 修飾子が有効になっていると，ターミナル回線に対する次の着信が，前のユーザのプロセスに接続される可能性があります。 /COMMSYNC 修飾子は，モデム信号をフロー制御として使用することにより，非同期プリンタなどのデバイスのターミナル・ポートへの接続を可能にすることを目的としています。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
