この章では,ユーザ・グループを設計する方法と,作業の実行に必要な識別情報 (UIC,識別子,特権) をユーザに与える方法について説明します。システムのデータと資源を適切に保護すると同時に,ユーザが効率的に作業できるよう,適切な保護コードと ACL をオブジェクトに割り当てる方法も示します。この章では,読者が第 4 章と第 5 章の内容を習得していることを前提としています。
8.1 ユーザ・グループの設計
ユーザ・グループを設計する際には,セキュリティ管理者が作成するグループは,データと資源の保護に影響を与え,GROUP,GRPNAM,および GRPPRV 特権を受けるユーザに影響する点に留意してください。ユーザの職務に応じてグループ分けする方法が考えられます。会計,エンジニアリング,マーケティング,人事など共通の職務を行うユーザのグループを調べます。
また,組織における将来の計画を見越し, これらの考えを戦略に組み込みます。グループの設計の微調整はいつでもできますが,ユーザの職務に応じた合理的なグループ分けを把握することが最も重要です。
UIC グループへのユーザの配置を決定するには,次の 2 つのガイドラインに従います。
共有 : 普段からデータおよびプロセスの制御をお互いに共有するユーザは,同じグループに配置します。
保護 : お互いのデータへのアクセス,またはお互いのプロセスの制御が禁止されているユーザ同士は,別々のグループに割り当てます。
ただし,UIC グループの設計には制約があります。セキュリティ管理者が所有するファイルへのアクセス権を,UIC グループの少数のメンバにのみ与えることも,ワールド・アクセス権を付与することなく,セキュリティ管理者のファイルへのアクセス権を複数の UIC グループのメンバに付与することもできます。これらの制約については,8.1.2 項で説明しています。
8.1.1 UIC グループの設計の例
架空の Rainbow Paint Company は,経営執行,会計,マーケティング,発送,管理の,5 つの部署がある流通企業です。表 8-1
に,さまざまな部署における,コンピュータ資源を必要とする従業員を示します。この表には,従業員が担当する職務の一覧も示します。
表 8-1: 部署と職務による従業員のグループ分け
| 部署 | 従業員名 | 職務 |
経営執行 |
Samuel Gibson |
社長 |
Olivia Westwood |
コンピュータ運用の責任者 |
|
会計 |
Carlo Ruiz |
給与計算 |
Rich Smith |
経理 |
|
Rod Jacobs |
事務員 |
|
Ruth Ross |
事務員 |
|
マーケティング |
Jason Chang |
市場予測 |
Alana Mack |
売り上げ報告 |
|
発送 |
Scott Giles |
在庫管理 |
管理 |
Jane Simon |
通信管理/給与小切手印刷 |
この会社が複数の部署に編成されていることは,同じ部署の人員は,多くの同じ職務を遂行することを意味します。たとえば,この会社で経理作業を行う全従業員を,会計課にグループ分けする利点は,従業員の相互連絡と,共有しなければならないデータへのアクセスが簡単に行える点です。
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 グループのメンバには,次の例のように,ファイルへの共通のアクセス権を付与することができます。
$ SET SECURITY/PROTECTION=G:RWE GROUP_STATS.DAT
このコマンドを使用して,ファイル GROUP_STATS.DAT の所有者は,UIC グループの各メンバに,ファイルに対する読み込みアクセス権,書き込みアクセス権,および実行アクセス権を許可します。
8.1.2 UIC グループの設計に関する制約
場合によって UIC ベースの保護が,オブジェクト保護のニーズに対する最適のソリューションではないことがあります。複数の UIC グループのユーザが,システム上の共通ファイルなどの資源へのアクセス権を必要とする場合,UIC ベースの保護で利用できる方法は,そのオブジェクトに対するワールド・アクセス権を付与する方法か (全ユーザがそのオブジェクトにアクセスできる),各ユーザの特権を拡張する方法のみです。どちらの選択肢も望ましくありません。
また,UIC グループのユーザに複数のタイプのファイル・アクセス権を許可したり,同じグループ内の一部のユーザに対して,オブジェクトへのアクセス権を付与しない必要がある場合もあります。このような場合も,UIC ベースの保護は,これらのニーズを満たす適切なソリューションではありません。
以降の節で説明するアクセス制御リスト (ACL) は,システム上のファイルなどのオブジェクトを保護する別の手段を提供します。
4.5 節「保護コードによるアクセスの制御」で説明しているように,サイトのセキュリティ管理者は,UIC のカテゴリの詳細を十分認識することが非常に重要になります。特定の UIC グループにユーザを入れることで,そのユーザにシステム特権を付与できます。また,システム特権を持つユーザは,システム上のすべての保護オブジェクトに対する制御アクセス権を持っています。SYSPRV 特権は,デフォルトでは 10 以下のすべての UIC グループに付与されますが,システム UIC カテゴリの実際の範囲は,MAXSYSGROUP システム・パラメータの値によって決まります。システム・ファイルを所有するグループに,GRPPRV 特権を持つユーザを入れると,セキュリティ上問題になる場合があります。
8.2 ACL での個別ユーザの指定
データと資源の保護の問題を解決するために,UIC グループを再構築するではなく,アクセス制御リスト (ACL) を使用して目的を達成できる場合があります。ACL の詳細については,4.4 節「ACL によるアクセスの制御」で説明しています。UIC は ACE において識別子として機能するため,簡単に ACL を作成して,さまざまな UIC グループの特定のユーザに,オブジェクトへのアクセスを許可することができます。
たとえば,Rainbow Paint Company の特定のユーザに,PAYROLL.DAT ファイルへのアクセスを許可する,次のような ACL を作成する場合を考えます。
(IDENTIFIER=OWESTWOOD,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=CRUIZ,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=RSMITH,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=JSIMON,ACCESS=READ)
(IDENTIFIER=SGIBSON,ACCESS=READ)
多数のユーザが同じアクセス権を必要とする場合があります。しかし,UIC 識別子のみで構成される ACL は,長くなりすぎることがあります。ACL を短縮するために,システム定義の環境識別子を含めたり,汎用識別子を作成することができます (表 4-1表 4-1 を参照)。
汎用識別子を作成する際には,システムで必要な識別子の名前を考え,その識別子の保持者のセットを作成します。続いて,識別子をライト・データベースに追加し,識別子を該当するユーザに割り当てます。
たとえば,Rainbow Paint Company で PAYROLL 識別子をライト・データベースに追加することにしたとします。その識別子の保持者は,PAYROLL.DAT に対する読み込みアクセス権,書き込みアクセス権,実行アクセス権,および削除アクセス権を必要とする全ユーザで,OWESTWOOD,CRUIZ,および RSMITH です。
識別子とその保持者を定義したら,セキュリティ管理者は次の ACL を使用して,同じタイプのアクセス権を PAYROLL.DAT に指定します。
(IDENTIFIER=PAYROLL,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=JSIMON,ACCESS=READ)
(IDENTIFIER=SGIBSON,ACCESS=READ)
ACL と識別子の設計の最終ステップは,それぞれの識別子がいつどのように使用されるかを考慮することです。ユーザは多くの場合,データベースの更新やシステム操作の実行など,さまざまな目的のために識別子を保持します。このため,識別子の使用を限定したい場合があります。
識別子の使用を限定する方法はいくつかあります。1 つは,環境識別子を使用する方法で,もう 1 つは 8.6.7 項で説明しているように,識別子に特別な属性を追加する方法です。
環境識別子は,ユーザがシステムに最初に入ったときの方法に応じた,さまざまなタイプのユーザを規定します。ローカル,ダイアルアップ,遠隔,会話型,ネットワーク,およびバッチのいずれかとなるこれらの識別子は,ユーザがシステムを使用する形態に応じて,大規模なユーザ・グループを定義することができます。一般的にこれらのタイプの識別子は,ほかの識別子と組み合わせて使用します。
たとえば次の ACE は,ローカル・ターミナルからログインした場合にのみ,オブジェクトに対する読み込みアクセス権,書き込みアクセス権,実行アクセス権,および削除アクセス権をユーザ Martin に許可します。
(IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE)
ACL で環境識別子を使用して,特定のログインのクラス全体に対して,アクセスを拒否することができます。たとえば,次の ACE はすべてのダイアルアップ・ユーザに対して,アクセスを拒否します。
(IDENTIFIER=DIALUP,ACCESS=NONE)
DECwindows 環境のユーザにこれらの環境識別子を割り当てる際には,DECwindows プロセスは事実上任意のタイプのプロセスになりうる点に留意してください。たとえば,ユーザはバッチ・ジョブの中で DECwindows Mail を実行できます。プロセスが DECwindows ワークステーションを介してユーザと会話型の通信を行っている場合であっても,そのプロセスはバッチ・ジョブに分類されます。
8.5 ACL の設計
汎用識別子を用いた短い ACL を使用すると,いくつかのメリットがあります。オペレーティング・システムは,ACL が短ければ,処理が高速になります。また,従業員の異動があっても職務が同じままであれば,システム全体で各 ACL を変更しなくても済みます。その代わりに,識別子の保持者を変更します。従業員がプロジェクトを離れる場合は,RIGHTSLIST.DAT にあるその従業員のレコードを編集して,以後その従業員が識別子を保持しないようにします。また従業員が退職する場合は,ユーザ登録ファイル (UAF) から従業員のレコードをまるごと削除できます。同じ仕事を担当する新しい従業員が雇用された場合は,その識別子を保持する権限を新しいユーザに付与します。これで,新しいユーザは,前のユーザと同じ ACL ベースのアクセス権を持つことになります。
設計の全般では,システム上のファイルなどのオブジェクトのタイプと,各オブジェクトの保護の要件を考慮する必要があります。グループと識別子を正しく指定すれば,ACL の設計と標準的な保護の定義が簡単にできるはずです。ユーザの共通のアクセス要件を明らかにすることにかけた時間だけ,識別子と ACL の設計が簡単になります。また,自分のファイルに ACL を適用するユーザの作業も簡単になります。
ACL を多用し過ぎないようにしてください。ACL は,ファイルがオープンされていると,システムの動的なページング・メモリを消費します。また,処理時間も余分に必要になります。ACL の適用が最適であるのは,保護が実際に必要な場面です。ACL が長すぎる (たとえば 200 エントリを超える) 場合は,ユーザを個別のカテゴリにグループ分けし,汎用識別子を作成することを検討します。
同時に,作成する識別子の数は適度に制限します。特に,1 人のユーザにあまりに多くの識別子を付与しないでください。1 人のユーザに 10 〜 20 個以上の識別子があると,ACL の処理に過剰な時間が費やされます。あまりに多くの識別子を保持しているユーザが見つかった場合は,グループの構造を再検討するとよいでしょう。または,そのユーザが例外的なケースである場合は,その個人を必要な ACL に直接入れることを検討します。
識別子の定義の詳細については,8.6 節と,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の AUTHORIZE の説明を参照してください。ACL の作成と保守の詳細については,第 4 章を参照してください。作業が多い場合は,アクセス制御リスト・エディタ (ACL エディタ) を使用するとよいでしょう。ACL エディタについては,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』で説明しています。
8.6 ライト・データベースへの登録
システムで必要な識別子の名前を考え,識別子の保持者のセットを作成したら,AUTHORIZE を使用して識別子をライト・データベースに追加し,対象ユーザに識別子を割り当てます。これらの関連付けは,ライト・データベース (RIGHTSLIST.DAT) に保持されます。ライト・データベースは,ユーザと識別子の追加/削除を行うことで保守します。
ライト・データベースは,初めにシステムのインストール時に作成され,[SYSEXE] ディレクトリにあります。作成時にライト・データベースには,環境識別子の名前が含まれています。登録ファイルにユーザを追加すると,登録したユーザごとに 1 つの識別子が追加されます。UIC 識別子と呼ばれるこの識別子は,ユーザの UIC およびユーザ名と関連付けられています。
ライト・データベースにも,各 UIC グループ名に相当する識別子があります。新しい UIC グループの最初のメンバとして新規ユーザを追加し,そのユーザにアカウント・グループ名を指定すると,次の例のように,アカウント・グループ名に対応する識別子がライト・データベースに追加されます。
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] -
_UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMT
UAF-I-ADDMSG, user record successfully added
UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006]
added to RIGHTSLIST.DAT
UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777]
added to RIGHTSLIST.DAT
ROB のアカウントを追加する際にアカウント名 MGMT を指定していますが,その名前の UIC グループが存在しないため,ライト・データベースに MGMT 識別子が追加されます。
各サイトは,実際の使用状況と要件に従って,それぞれのライト・データベースを合わせていきます。
AUTHORIZE を使用してシステム・ユーザ登録ファイル (SYSUAF.DAT) のユーザ名の追加,削除または変更を行うと,ライト・リストが SYSUAF.DAT に対応するように,AUTHORIZE によって対応する変更が RIGHTSLIST.DAT に加えられます。
ライト・データベースの作成と保守は自動的に行われるため,AUTHORIZE の CREATE/RIGHTS コマンドは,ほとんど使用する必要がありません。ただし,ライト・データベースが破損したり削除された場合は,このコマンドを使用して新しいライト・データベースを作成できます。詳細については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。
8.6.1 データベースの表示
定期的にライト・データベースを表示して,ライト・データベースが正確で,情報が最新であることを確認する必要があります。このためには,2 つの AUTHORIZE の SHOW/IDENTIFIER コマンドと SHOW/RIGHTS コマンドを使用します。ある識別子のすべての保持者を表示するには,次の例のように SHOW/IDENTIFIER コマンドを使用します。
UAF> SHOW/IDENTIFIER/FULL NETWORK
システム上の全識別子の全保持者を表示するには,次のようにアスタリスク (*) ワールドカードを使用します。
UAF> SHOW/IDENTIFIER/FULL *
特定のユーザが保持する識別子を表示するには,次のように SHOW/RIGHTS コマンドを使用します。
UAF> SHOW/RIGHTS/USER=ROBIN
全ユーザが保持する全識別子を表示するには,次のようにアスタリスクのワイルドカードを使用します。
UAF> SHOW/RIGHTS/USER=*
UAF> SHOW/RIGHTS/USER=[*,*]
最初のコマンドにより,ユーザがアルファベット順で表示されます。2 番目のコマンドでは,UIC 順にユーザが表示されます。
8.6.2 識別子の追加
ライト・リストに識別子を追加するには,次のように AUTHORIZE の ADD/IDENTIFIER コマンドを使用します。
UAF> ADD/IDENTIFIER PAYROLL
identifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT
8.6.7 項 で説明している属性を使用してユーザに識別子を付与するには,識別子を追加する際にその属性を指定する必要があります。たとえば,識別子の追加または変更をユーザに許可するには,Dynamic 属性を指定します。
UAF> ADD/IDENTIFIER PROJECT_TEAM1 /ATTRIBUTES=DYNAMIC
誤ってライト・リストを削除してしまい,バックアップ・コピーからも復元できない場合は,次のように CREATE/RIGHTS コマンドを入力し,その後に ADD/IDENTIFIER コマンドを入力して,RIGHTSLIST.DAT を再度作成します。
UAF> CREATE/RIGHTS
{message}
UAF> ADD/IDENTIFIER/USER=* or ADD/IDENTIFIER/USER=[*,*]
{messages}
ADD/IDENTIFIER コマンドは,ライト・リストに,SYSUAF.DAT の各ユーザ名に対応する UIC 識別子を作成します。この作業を完了するには,ADD/IDENTIFIER コマンドを使用して,失われたすべての汎用識別子を追加します。続いて,8.6.4 項で説明している方法で,GRANT/IDENTIFIER コマンドを使用して識別子の保持者を再定義します。
8.6.4 ユーザへの識別子の割り当て
識別子を追加した後,次の例のように AUTHORIZE の GRANT/IDENTIFIER コマンドを使用して,既存の識別子の保持者としてユーザを関連付けます。
UAF> GRANT/IDENTIFIER PAYROLL MARTIN
UAF-I-GRANTMSG, identifier PAYROLL granted to MARTIN
UAF> GRANT/IDENTIFIER PAYROLL IPPOLITO
UAF-I-GRANTMSG, identifier PAYROLL granted to IPPOLITO
ユーザ Martin に,PAYROLL 識別子に加えて EXECUTIVE 識別子を付与するには,GRANT/IDENTIFIER コマンドを再度使用する必要があります。GRANT/IDENTIFIER コマンドでは,一度に 1 つのみ保持者の関連付けを行うことができます。
上記のすべての例で,AUTHORIZE を使用して,ユーザ (具体的には Martin と Ippolito) に対応する UIC 識別子に PAYROLL 識別子を関連付けています。識別子は両方ともライト・データベースに存在する必要があります。
8.6.5 保持者レコードの削除
ユーザが退職した場合は,そのユーザの UAF レコードを削除します。そのユーザが代理アカウントにアクセスできるすべてのサイトの管理者に通知して,遠隔ノードの NETPROXY.DAT ファイルにある代理アクセス情報を削除してもらいます。AUTHORIZE を実行してユーザの UAF レコードを削除すると,AUTHORIZE によって,ライト・データベースにある識別子の保持者としてのユーザの関連付けも削除されます。ただし,退職したユーザが特定の識別子の唯一の保持者である場合は,今後の混乱を避けるために,その識別子を削除します。
8.6.6 識別子の削除
ライト・データベースから識別子を削除する前には,次の操作を行います。
システムの ACL から,対象識別子の出現をすべて削除します。たとえば次のコマンドは,複数のファイルの ACL から,古い識別子 87SUMMER を削除します。
$ SET SECURITY/ACL=(IDENTIFIER=87SUMMER)-
_$/DELETE/LOG *.*;*
ACE が含まれないファイルに関するエラーが表示されますが,ACE が含まれる全ファイルからは ACE が削除されます。
識別子 87SUMMER をライト・データベースから削除するには,AUTHORIZE の REMOVE/IDENTIFIER コマンドを使用します。たとえば,識別子 87TERM3 を削除するには,次の AUTHORIZE コマンドを使用します。
UAF> REMOVE/IDENTIFIER 87TERM3
{message}
ACE に 16 進形式の識別子がある場合,それは汎用識別子がライト・データベースから削除されていることを示します。同様に,識別子が数値形式の UIC として表示されている場合,元の識別子は UIC で,削除されていることを示します。数値形式の UIC または 16 進形式の識別子を持つ ACE は削除します。
従業員の退職後には,UIC を再利用しないことをお勧めします。新しい従業員が,数値形式の古い UIC を依然として参照している ACL エントリを通じて,前任の従業員のアクセス権の一部またはすべてを手に入れる場合があるためです。
識別子の名前を変更するには,次の形式で AUTHORIZE の RENAME/IDENTIFIER コマンドを使用します。
RENAME/IDENTIFIER old-identifier new-identifier
識別子の名前を変更しても,以前の識別子を通じて利用できた資源のセットは維持されます。名前を変更した識別子が含まれる ACL は,自動的に新しい識別子名を表示します。
8.6.7 識別子のカスタマイズ
ライト・リストに識別子を追加する時,あるいは,ユーザに識別子を付与する時,その識別子に属性と呼ばれる特別な特性を持たせることができます。使用可能な属性は数多くありますが,大半のサイトでは次の属性をよく使用します。
多くの場合,セキュリティ要件が高いサイトでは,以上の他に,ユーザによるライト・データベースの検索を防止する次の 2 つの属性を使用します。
Holder Hidden 属性 |
識別子を所有している本人でない限り,その識別子を割り当てられているユーザのリストを取得することを禁止します。 |
Name Hidden 属性 |
識別子の保持者に,識別子の変換 (バイナリから ASCII,またはその逆) を許可しますが,権限のないユーザが識別子を変換することを禁止します。 |
RIGHTSLIST.DAT への読み取りアクセス権は,Holder Hidden 属性および Name Hidden 属性をオーバーライドします。デフォルトでは,ライト・リストはワールド・ユーザにアクセス権を付与しません。ライト・リストの保護は,"S:RWED,O;RWED,G:R,W:" となっています。
以降の節では各属性について解説し,どのような場合にサイトの識別子の一部に属性を追加する必要があるかを説明します。
8.6.7.1 Dynamic 属性
ユーザに識別子を付与すると,そのユーザによって作成されるプロセスは,プロセスが存続し続ける間,識別子を保持します。しかし,Dynamic 属性を指定した識別子を付与すると,その識別子を保持するユーザは,DCL の SET RIGHTS_LIST コマンドを使用して,必要に応じてプロセス・ライト・リストを対象に識別子またはその属性の追加/削除を行うことができます。
識別子の変更をユーザに許可するには,次の例のように AUTHORIZE を使用して,ライト・データベースに識別子を追加する際に Dynamic 属性を指定します。
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC
識別子の特定の保持者に識別子の変更を許可するには,次のように,識別子を付与する際に Dynamic 属性を追加します。
UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=DYNAMIC SCHWARTZ
以降,ユーザ Schwartz は,次のコマンドを使用してプロセス・ライト・リストから MGMT101 識別子を削除できます。
$ SET RIGHTS_LIST/DISABLE MGMT101
また,Dynamic 属性と Resource 属性を持つ識別子を保持するユーザは,SET RIGHTS_LIST コマンドを使用してその識別子の Resource 属性のみを削除できます。
識別子を削除することで,設定されているセキュリティ・ポリシーをユーザが回避できる場合があるため,Dynamic 属性を持つ識別子をユーザに付与する際には注意してください。Dynamic 属性を持つ識別子を保持するユーザにアクセス権を付与しないために,ACL で識別子が使用されている場合,ユーザは,プロセス・ライト・リストから識別子を削除することで,別の ACL エントリを通じてオブジェクトへのアクセス権を取得できる場合があります。
8.6.7.2 Holder Hidden 属性
セキュリティ要件が高いサイトでは,特定の識別子の保持者を隠して,侵入のターゲットとして望ましいアカウントを悪意のあるユーザが判定できないようにすることが可能です。
AUTHORIZE の MODIFY/IDENTIFIER コマンドを使用して,ユーザが保持する識別子に属性を適用します。次に例を示します。
UAF> MODIFY/IDENTIFIER /ATTRIBUTES=HOLDER_HIDDEN SECRET_PROJECT
これで,詮索行為を行う人物は,秘密プロジェクトに関与している人物がわからなくなります。
8.6.7.3 Name Hidden 属性
セキュリティ要件が高いサイトでは,識別子の名前を隠すことができます。たとえば,強制アクセス制御を実装するサイトでは,セキュリティ・カテゴリに関連付けられた識別子の名前を隠すことができます。これにより,識別子を保持する本人でなければ,識別子の名前を表示できなくなります。識別子に Name Hidden 属性が指定されている場合,要求側のプロセスがその識別子を保持している場合を除き,オペレーティング・システムは,バイナリ値から ASCII または ASCII からバイナリ値への識別子の変換を拒否します。
この属性を識別子に割り当てるには,次のように AUTHORIZE の MODIFY/IDENTIFIER コマンドを使用します。
UAF> MODIFY/IDENTIFIER SECRET_NEWS /ATTRIBUTES=NAME_HIDDEN
No Access 属性は,識別子の保持をプロセスに許可しますが,オブジェクトへのアクセス権の判定において,その識別子を考慮しないようにします。
たとえば,Resource 属性と No Access 属性を持つユーザは,識別子にディスク領域を割り当てることができますが,その識別子が所有するオブジェクトにはアクセスできません。また,システム管理者はデータを管理し,そのデータに関連する作業を実行できますが,ファイルの読み書きはできません。
セキュリティ管理者は,識別子によるファイル領域の所有,および識別子へのファイル領域の割り当てを許可する一方で,ファイル・アクセスを禁止することができます。ライト・データベースに識別子を追加する際に,Resource 属性とともに No Access 属性を指定するには,次の例のように AUTHORIZE を使用します。
UAF> ADD/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-
_UAF> MGMT101
Resource 属性を持つ識別子を保持するユーザの権限を制限するには,次のように,対象の全ユーザに対して,Resource 属性のほかに No Access 属性も付属する識別子を付与します。
UAF> GRANT/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-
_UAF> MGMT101 SCHWARTZ
一般的にディスク領域の消費は,ファイル所有者のディスク制限からディスク領域を差し引くことにより,各ファイルの作成者に割り当てられます。システム管理者とセキュリティ管理者は,個別ユーザではなく,(部署やプロジェクトなどの) ユーザの論理グループに従って,ディスク領域の使用状況を追跡することが望ましい場合があります。このようなグループの指定には,汎用識別子を使用します。したがって,汎用識別子がディレクトリを所有する場合,ディレクトリに作成されたファイルにより使用されるディスク領域は,ファイルの作成者の UIC ではなく,識別子に割り当てられる場合があります。
ファイル領域を識別子が所有するようにして,識別子への割り当てを可能にするには,次の例のように,ライト・データベースに識別子を追加する際に,AUTHORIZE を使用して Resource 属性を指定します。
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=RESOURCE
識別子の特定の保持者に対して,識別子へのディスク領域の割り当てを許可するには,次の手順を実行します。
Resource 属性を持つ識別子を,すべての対象ユーザに付与します。
UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ
ディレクトリに変更を加え,資源識別子への読み込みアクセス権と書き込みアクセス権を許可します。
$ SET SECURITY/ACL=(-
_$ (IDENTIFIER=MGMT101,ACCESS=READ+WRITE ) -
_$ (IDENTIFIER=MGMT101,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
_$ INVENTORY.DIR
デフォルトで親ディレクトリ内のすべてのファイルが識別子に所有されるよう,親ディレクトリの所有権を変更します。
$ SET SECURITY/OWNER=MGMT01 INVENTORY.DIR
資源識別子 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 により所有され,必要なディスク領域はユーザのディスク制限から差し引かれます。
8.6.7.6 Subsystem 属性
Subsystem 属性を持つサブシステム識別子をユーザに付与することで,保護サブシステムを管理する権限をユーザに付与できます。これによりユーザは,サブシステムによって管理されるオブジェクトにイメージがアクセスできるようにすることが可能になります。保護サブシステムの説明については,第 13 章を参照してください。
次の例では,識別子 MAIL_SUBSYSTEM を使用して,ユーザ Schwartz にサブシステムを作成する権限を付与しています。また Schwartz には,アクセス制御を設定するためのアプリケーション・イメージへの制御アクセス権も付与しています。
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/IDENTIFIER MAIL_SUBSYSTEM /ATTRIBUTES=SUBSYSTEM
UAF> GRANT/IDENTIFIER MAIL_SUBSYSTEM -
_UAF> /ATTRIBUTES=SUBSYSTEM SCHWARTZ
UAF> Exit
$ SET SECURITY/ACL=(IDENTIFIER=MAIL_SUBSYSTEM,ACCESS=CONTROL)-
_$MEMBER_LIST.EXE
特権セキュリティ管理者は,SET RIGHTS_LIST コマンドを使用して,システム上の任意のプロセスのライト・リストを変更したり,システム・ライト・リストの識別子を変更できます。システム・ライト・リストに識別子を追加すると,その識別子を全ユーザに付与することになります。また,SET RIGHTS_LIST コマンドを使用して,既存の識別子に属性を追加することもできます。
システム・ライト・リストの使用法の 1 つに,サイト固有の環境条件の有効化があります。たとえば,午前 8 時に実行するスケジュールが組まれているバッチ・ジョブは,次の識別子を追加することができます。
$ SET RIGHTS_LIST/SYSTEM/ENABLE DAY_SHIFT
午後 5 時に実行するスケジュールが組まれている別のバッチ・ジョブは,次のように,識別子 DAY_SHIFT を削除することができます。
$ SET RIGHTS_LIST/SYSTEM/DISABLE DAY_SHIFT
結果的に,識別子 DAY_SHIFT を持つ保護オブジェクトへのアクセスが,午前 8 時から午後 5 時まで有効になります。
次の例のコマンドは,プロセス DEDNAM のライト・リストに SALES 識別子を追加することで,プロセス・ライト・リストを変更しています。Resource 属性を指定することで,SALES 識別子の保持者に,その識別子へのディスク領域の割り当てを可能にしています。
$ SET RIGHTS_LIST/ENABLE/ATTRIBUTES=RESOURCE/PROCESS=DEDNAM SALES
一部のシステム処理は,特定の特権を有するユーザに制限されます。このような制限により,オペレーティング・システムの性能の一貫性が守られる結果,ユーザに提供されるサービスの一貫性も保たれます。各ユーザへの特権の付与は,(a) 特権に対する正当なニーズがユーザにあるかどうか,(b) システムを妨害することなく特権を使用するスキルと経験をユーザが持っているかどうか,という 2 つの要素に基づいて判断します。
ユーザの特権は,そのユーザの UAF レコードに,2 つの特権ベクタとして記録されます。一方のベクタには許可された特権が格納され,もう一方のベクタにはデフォルトの特権が格納されます。デフォルトの特権は,ログイン時にユーザ・プロセスが獲得する,許可された特権のサブセットです。
ユーザがシステムにログインすると,ユーザの特権ベクタが,ユーザのプロセスのヘッダに保存されます。このようにして,そのユーザの特権は,ユーザに対して作成されるプロセスに渡されます。ユーザは,DCL の SET PROCESS/PRIVILEGES コマンドを使用して,ユーザに許可される特権を有効/無効にすることができます。
オペレーティング・システムは,特権の使用状況を監視および監査します。特定の特権に対する監査を有効にし,監査ログ・ファイルを調べることで,DCL コマンドまたはシステム・サービスの実行にどの特権が使用されたかを確認できます。詳細については,第 9 章を参照してください。
8.7.1 特権のカテゴリ
特権を有するユーザがシステムにもたらす可能性のある損害に従って,特権は次の 7 つのカテゴリに分けられています。
None : 特権なし
Normal : システムを有効に使用するための最低限の特権
Group : 同一グループのメンバに影響が及ぶ可能性
Devour : システム全体のクリティカルではない資源を消費する可能性
System : 通常のシステム操作に影響が及ぶ可能性
Objects : オブジェクトのセキュリティを危険にさらす可能性
All : システムを制御する可能性
表 8-2
に,特権の分類と,各特権に関連付けられている能力の簡単な定義を示します。
表 8-2: OpenVMS の特権
| カテゴリ | 特権 | 許可される処理 |
None |
None |
特権を必要とする処理を拒否 |
Normal |
NETMBX TMPMBX |
ネットワーク接続の作成,一時メールボックスの作成 |
Group |
GROUP GRPPRV |
同一グループのプロセスの制御,グループのオブジェクトのシステム保護フィールドを通じたアクセスの取得 |
Devour |
ACNT ALLSPOOL BUGCHK EXQUOTA GRPNAM PRMCEB PRMGBL PRMMBX SHMEM |
アカウントの無効化,スプールされたデバイスの割り当て,バグチェック・エラー・ログのエントリの作成,ディスク制限の超過,名前テーブルへのグループ論理名の挿入,パーマネント・コモン・イベント・フラグ・クラスタの作成/削除,パーマネント・グローバル・セクションの作成,パーマネント・メールボックスの作成,共有メモリでの構造体の作成/削除 |
System |
ALTPRI AUDIT OPER PSWAPM WORLD SECURITY SYSLCK |
割り当てよりも高いベース優先順位の設定,監査レコードの作成,オペレータ機能の実行,プロセス・スワップ・モードの変更,任意のプロセスの制御,セキュリティ関連機能の実行,システム全体の資源のロック |
Objects |
DIAGNOSE IMPORT MOUNT READALL SYSGBL VOLPRO |
デバイスの診断,ラベルのないテープ・ボリュームのマウント,マウント・ボリューム QIO の実行,全システム・オブジェクトに対する読み込みアクセス権の所有,システム全体のグローバル・セクションの作成,ボリューム保護のオーバーライド |
All |
BYPASS CMEXEC CMKRNL IMPERSONATE DOWNGRADE LOG_IO PFNMAP PHY_IO SETPRV SHARE SYSNAM SYSPRV UPGRADE |
保護の無視,エグゼクティブ・モードへの変更,カーネル・モードへの変更,任意の UIC の独立プロセスの作成,より低い秘密オブジェクトへの書き込みまたはオブジェクトの分類の低下,論理入出力要求の発行,特定の物理ページへのマッピング,物理入出力要求の発行,任意の特権の有効化,ほかのユーザに割り当てられたデバイスへのアクセス,名前テーブルへのシステム論理名の挿入,システム保護フィールドを通じたオブジェクトへのアクセス,より高い統一性オブジェクトへの書き込みまたはオブジェクトの統一性レベルの上昇 |
付録 A に,すべてのユーザ特権と,ユーザ特権を付与すべき条件に関する推奨事項を示します。ユーザ特権を割り当てる際には,慎重に行います。
表 8-3
の要約ガイドラインは,システム・ユーザの一般的なクラスに対する最低限の特権の要件です。
表 8-3: システム・ユーザの最低限の特権
| ユーザのタイプ | 最低限の特権 |
一般 |
TMPMBX,NETMBX |
オペレータ |
OPER |
グループ管理者 |
GROUP,GRPPRV |
システム管理者 |
SYSPRV,OPER,SYSNAM,CMKRNL [脚注 3] |
セキュリティ管理者 |
SECURITY,AUDIT,READALL |
特権を付与すると,セキュリティ管理者が特権を削除するまで,ユーザに特権が認められます。このような全面的な許可を避けるには,必要に応じて特権を付与するようにします。たとえば一部のユーザが,強力な特権のいずれかを必要とするプログラムを実行しなければならない場合があります。その場合には,インストール・ユーティリティ (INSTALL) を使用して,必要な特権を与えてプログラムをインストールします。8.7.4 項で,特権イメージのインストールを詳細に説明しています。
全面的な特権の付与に代わる方法としては,緊急または専用の特権アカウントを設定する方法があります。ユーザは,特定の機能を実行するためにのみ,このような特権アカウントにログインします。この方法には,次の 2 つの選択肢があります。
アカウントの存在を知っていて,その使用方法を知らされている,限定されたユーザのグループを作成する。
ユーザ用に 2 つのアカウントを作成し,一方のアカウントには特権を付与し,もう一方のアカウントには特権を付与しない。この場合,対象ユーザは両方のアカウントで,同じ UIC と同じデフォルト・ディレクトリを持ちます。これは,(実際に存在するユーザが 1 人のみであるため) UIC の共有が推奨される唯一のケースです。この二重アカウントの手法を採用する場合は,どのアカウントが特権アカウントであるかがわかるような,明白なユーザ名は避けます。
どちらの方法でも,長いパスワード,短いパスワード有効期間,時間帯の制限,操作モードの制限 (ダイアルアップ,ネットワーク,遠隔,またはバッチ・ログインは不可) など,特権アカウントに特別な制限を設定できます。また,アカウントの有効期間を短くすれば,特権の要件を頻繁に検討するように求められます。
もう 1 つの方法として,第 13 章で説明している保護サブシステムを使用して,システム特権の必要性をなくすという方法もあります。
8.7.4 特権イメージのインストール
必要な特権を有する既知イメージとしてイメージをインストールしない限り,ユーザは,そのユーザが所有していない特権を必要とするイメージは実行できません。既知イメージのインストール方法については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。特権を有する既知イメージを実行すると,イメージを実行している間,イメージを実行しているユーザ・プロセスに特権が付与されます。したがって,(HP が提供する通常の設定以外の) 強力な特権を有するイメージは,イメージの機能により特権が必要であり,イメージが安全に機能することが確認された後にのみインストールします。また,イメージへのアクセス権を,一部のユーザに制限することも検討してください。
特権を使用してインストールされたイメージは,強力な特権がすべて有効になった状態で起動されます。安全性を最大限にするため,強力な特権を使用して実行するよう設計されたイメージは,$SETPRV システム・サービスを使用して,すべての強力な特権を起動直後に無効にし,必要な場合にのみ有効化するべきです。
特権を有するイメージのインストールの例を次に示します。System Dump Analyzer (SDA) ユーティリティは,実行中のシステムを分析するために CMKRNL 特権が必要です。
次のように CMKRNL 特権を与えて,SDA.EXE をインストールします。
$ INSTALL SDA.EXE /PRIVILEGED=CMKRNL
次のように,SDA.EXE に ACL を適用し,UIC ベースの保護を設定して,ワールド・カテゴリのユーザにはすべてのアクセス権を拒否します。
$ SET SECURITY/ACL=(IDENTIFIER=SDA,ACCESS=EXECUTE)-
_$ SYS$SYSTEM:SDA.EXE
$ SET SECURITY/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE
SDA 識別子を保持するユーザが,プログラムを実行する予定のユーザであることを確認するには,AUTHORIZE コマンドを使用します。必要に応じて,このユーザ・リストを調整します。
注意
オンラインでのデバッグとトレースバックを防止するため,特権を与えてインストールするイメージはすべて,/NOTRACEBACK 修飾子を使用してリンクする必要があります。
HP により,オペレーティング・システムに付属するすべてのシステム・プログラム (SDA など) は,オンラインでのデバッグやトレースバックを防止するため,/NOTRACEBACK 修飾子を使用してリンクされています。
一部の DCL コマンドは,ユーザが保持する特権に応じて動作が異なります。
たとえば,ユーザが GROUP 特権または WORLD 特権を保持している場合を除き,SHOW PROCESS コマンドは,プロセス情報の表示をユーザのプロセスに限定します。GROUP 特権を持つユーザは,自身が所属する UIC グループの他のプロセスを表示できます。また,WORLD 特権を持つユーザは,システム上の任意のプロセスを表示できます。
8.8 デフォルトの保護と所有権の設定
ユーザのグループと識別子を設計したら,どの保護オブジェクトに対するアクセス許可をユーザが必要とし,どの保護オブジェクトの制限を解除できるかを検討する必要があります。第 5 章に示す新しいオブジェクトのデフォルトの保護を十分に把握し,必要な場合は,以降の節で説明する手順でデフォルトを変更します。
オブジェクトの保護と所有権のデフォルトを設定する手順は,オブジェクトがファイルであるか,別のクラスの保護オブジェクトであるかに応じて異なります。
8.8.1 ファイル・アクセスの制御
5.4.5 項「プロファイルの割り当て」で説明しているように,ユーザに影響を与える保護のデフォルトを指定できる領域は,4 つ存在します。影響が大きい順に,次のとおりです。
システム・パラメータ RMS_FILEPROT は,ファイル保護に関するシステム全体でのデフォルトを設定します。RMS_FILEPROT の値は,AUTOGEN を使用して変更できます。ただし,この値は,次のデフォルト設定によりオーバーライドされる場合があります。
DCL の SET PROTECTION/DEFAULT コマンドを使用して,ターミナル・セッション中にユーザが作成または修正するファイルに適用されるファイル保護を指定できます。通常このコマンドはユーザのログイン・コマンド・プロシージャに含まれていますが,ユーザがこのコマンドをセッション中の任意の時点で入力し,SET PROTECTION/DEFAULT コマンドによって事前に設定された値をオーバーライドすることもできます。SET PROTECTION/DEFAULT コマンドは,該当ユーザに対するシステム全体の保護設定を無効にします。
特定のディレクトリに対するデフォルトの保護設定は,ディレクトリに適用される ACL で指定できます。ディレクトリに対するデフォルトの保護用 ACE が存在する場合,ディレクトリに追加されるすべての新しいファイル (サブディレクトリおよびそこに格納されるファイルを含む) は,この保護コードの対象になります。このコードは,システム全体のデフォルト設定と,(存在する場合は) ユーザ指定のデフォルト設定をオーバーライドします。
作成されるファイルが,ファイルを作成するプロセスのユーザ識別コード (UIC) により所有されない特別なケース (たとえば,ディレクトリが資源識別子により所有されている場合) では,その新しいファイルのデフォルトの保護を,ディレクトリの ACL 内の作成者 ACE によって変更できます。作成者 ACE の説明については,5.4.5 項「プロファイルの割り当て」を参照してください。
また,DCL の SET VOLUME/PROTECTION コマンドによってボリュームに課せられる保護も考慮します。この保護コードが指定されている場合は,ディレクトリおよびファイルに対する保護コードに関係なく,ボリュームのあらゆる部分への該当ユーザによるアクセスが禁止されます。SET VOLUME コマンドを使用してボリューム保護を指定していない場合,該当ボリュームには全ユーザがアクセスできます。
ファイル所有権の割り当ては,保護チェックの結果に影響します。この組み合わせによる保護構造の運用上の効果を,図 8-1,図 8-2,および図 8-3
に示します。
図 8-1: ファイル作成のフローチャート
デフォルトの動作を制御するために調整を行うことができます。システム・パラメータ 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 コマンドによって,必要なデフォルトの保護を実現できます。
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED)-
_$ [PROJECT]DIARY.DIR
この ACE がディレクトリ・ファイルに適用されると,そのディレクトリで作成または変更されるファイルは,デフォルトの保護コードの対象になります。これらの保護コードはデフォルトにすぎないため,ディレクトリ内のファイルへの制御アクセス権を持つユーザは,次の DCL コマンドを使用することで,ファイルのデフォルト値の置き換えとして,固有の保護コードを含めることができます。
SET SECURITY/PROTECTION
COPY/PROTECTION
APPEND/PROTECTION
CREATE/PROTECTION
デフォルトの保護コードを置き換えると,新しいコードがデフォルトとなり,それ以降のバージョンのファイルに反映されます。
一部のユーザに特別なログイン・コマンド・プロシージャを用意する場合,対象グループのユーザに対して,システム・パラメータ RMS_FILEPROT により指定されるシステム全体のデフォルトのプロセス保護を追加することができます。デフォルトのプロセス保護を指定するには,次のように,ログイン・コマンド・プロシージャに SET PROTECTION/DEFAULT コマンドを追加します。
SET PROTECTION=(S:RWED,O:RWED,G,W)/DEFAULT
ユーザのディレクトリに作成されたファイルは,明示的にオーバーライドする場合を除き,このデフォルトの保護コードが適用されます。
8.8.1.2 資源識別子により所有されるディレクトリのデフォルトの設定
より柔軟性の高いデータ管理と,より正確なディスク使用量の会計管理を実現するために,資源識別子に所有されるディレクトリを設定し,ACL を使用して,ディレクトリとディレクトリ内で作成されるファイルへのアクセス権を制御することができます。
ACL は,プロジェクト識別子を保持するすべてのプロジェクトのメンバに対して,ファイル・アクセスを制限できます。このようなアクセス制限を実現するには,識別子用 ACE を追加して,ファイルへのグループのアクセス権を定義します。追加される 2 つ目の識別子用 ACE は,最初の識別子用 ACE の複製ですが,Default 属性を保持しています。この Default 属性によって,ディレクトリ内で作成される全ファイルに,その ACE がコピーされることが保証されます。ディレクトリのデフォルトの保護コードによっては,3 つ目の ACE であるデフォルトの保護用 ACE が必要になる場合があります。デフォルトの保護用 ACE は,ディレクトリのファイルに対する保護コードを設定します。4.3 節「システムによる保護オブジェクトへのユーザのアクセス可否の判定」の説明にあるように,ACL によってファイルへのアクセスが禁止されている場合であっても,保護コードを通してアクセス権を得ることが可能です。
ACL は,ファイルへのグループのアクセスを制限するだけでなく,共通ディレクトリ内にユーザが作成したファイルに対するユーザのアクセス権のタイプを制御できます。ファイルは資源識別子のディレクトリに作成されるため,資源識別子がそのファイルを所有します。ユーザが作成したファイルにユーザ自身がアクセスするために,オペレーティング・システムは通常,ファイルの作成者に対して制御アクセス権を付与するだけでなく,保護コードの所有者フィールドで指定されているアクセス権も付与します。ただし,ディレクトリの ACL に作成者 ACE を追加することで,この動作を変更できます。作成者 ACE は,ユーザがプロジェクトのディレクトリに作成したファイルに対してユーザが保持するアクセス権のタイプを定義します。
8.8.1.2.1 資源識別子の設定
セキュリティ管理者が,次のコマンド・シーケンスを使用してプロジェクト識別子 PROJECTX を設定し,それをプロジェクトのメンバに付与したとします。プロジェクト識別子を,資源識別子を持っているライト・データベースに追加しているほか,資源識別子を持つユーザにも付与しています。プロジェクト識別子は,ディスク領域を所有できるように,Resource 属性を持つ必要があります。
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCE
UAF> GRANT/IDENTIFIER PROJECTX user1 /ATTRIBUTES=RESOURCE
UAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE
.
.
.
プロジェクトや部署に固有の識別子がディレクトリの所有者である場合,そのディレクトリに作成されるファイルによって使用される領域は,ファイルを作成した個人ではなく,適切な部署やプロジェクトに割り当てることができます。ユーザが複数のプロジェクトに関わっている場合は,ユーザの個人用アカウントではなく,該当するプロジェクトにディスク領域の要件を割り当てることができます。
資源識別子が保有するディレクトリを設定する際には,まずプロジェクト識別子に許可されるディスク制限を作成します。たとえば,次のコマンドはシステム管理ユーティリティ (SYSMAN) を起動し,超過値を 200 ブロックとして,識別子 PROJECTX に 2000 ブロックのディスク制限を割り当てています。
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200
ディスク制限を設定したら,プロジェクト・ディレクトリを作成します。たとえば,次の DCL コマンドでは,プロジェクト・ディレクトリ [PROJECTX] を作成し,その所有者として識別子 PROJECTX を設定しています。
$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX]
ディレクトリ [PROJECTX] を設定する際には,ACL を使用して,プロジェクトのメンバにファイル・アクセス権を付与します。次の例に,複数の ACE を使用してアクセス権を定義する方法を示します。
$ SET SECURITY [PROJECTX] /ACL= (-
_$ (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),- [1]
_$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),- [2]
_$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),-
_$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)) [3]
デフォルトの保護用 ACEは,ディレクトリ内に作成されるファイルに対して保護コードを設定します。この ACE は,グループ・ユーザおよびワールド・ユーザにはアクセス権を付与しません。
最初の識別子用 ACE は,PROJECTX 識別子の保持者に,ディレクトリの読み込みアクセス権,書き込みアクセス権,および実行アクセス権を付与します。
2 番目の識別子用 ACE は,ディレクトリに作成されるすべてのファイルが,最初の識別子用 ACE を保持することを保証します。
作成者 ACE は,PROJECTX ディレクトリにファイルを作成するユーザに,そのファイルの読み込みアクセス権,書き込みアクセス権,実行アクセス権,および削除アクセス権を付与することを指定します。
したがって,プロジェクトのメンバ Ross が [PROJECTX] ディレクトリにファイル SEPTEMBER-REPORTS.TXT を作成すると,ファイルには次のセキュリティ・プロファイルが与えられます。
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT
SEPTEMBER-REPORTS.TXT object of class FILE
Owner: [PROJECTX]
Protection: (System: RWED, Owner: RWED, Group, World)
Access Control List:
(IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)
プロジェクトのメンバは,ほかのユーザにより作成されたファイルを削除 (または制御) することは許可されていませんが,作成者 ACE によって,ユーザ自身が作成したファイルの削除アクセス権がユーザに与えられます。
作成者 ACE がない場合,プロジェクトの各メンバは,自分がディレクトリに作成したファイルへの完全なアクセス権を持っています。たとえば Ross には,プロジェクトのディレクトリに作成されたファイルへの,次のアクセス権が与えられます。
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT
SEPTEMBER-REPORTS.TXT object of class FILE
Owner: [ROSS]
Protection: (System: RWED, Owner: RWED, Group, World)
Access Control List:
(IDENTIFIER=ROSS,OPTIONS=NOPROPAGATE,
ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)
この動作を無効にするには,ACL に対して,ACCESS=NONE を指定する作成者 ACE を追加します。
8.8.2 ファイル以外のオブジェクトのデフォルトの設定
ファイルと擬似ターミナル (FT) デバイスを除き,保護オブジェクトの全クラスに,新しいオブジェクトに対するセキュリティ要素を提供する 1 つ以上のテンプレート・プロファイルが用意されています。したがって,1 つのメカニズムで,オブジェクトに関するデフォルトの保護コード,ACL,および所有権の要素を設定することができます。あるシステム・スタートアップから次のシステム・スタートアップに移っても,これらの値が使用できるように,オペレーティング・システムは常にこれらの値を保存します。SHOW SECURITY コマンドを使用して,自分のサイトの現在のデフォルト値を表示できます。オペレーティング・システムのデフォルト値の一覧については,第 5 章を参照してください。
オペレーティング・システムは,セキュリティ・クラス・オブジェクトにより保存されたデータから,新しいオブジェクトのセキュリティ・プロファイルを作成します。これらのオブジェクトはすべて論理構造であり,有効なアクセス・タイプ,テンプレート,および有効になっている監査のタイプなどのクラス要素を追跡するために使用されます。図 8-4
に示すように,保護オブジェクトの各クラスは,セキュリティ・クラスのメンバを持っています。独自の規則が適用されるメンバであるファイルを除き,すべてのメンバには,セキュリティ・プロファイル・テンプレートがあります。
図 8-4: セキュリティ・クラス・オブジェクト
クラス・テンプレートを表示するには,SHOW SECURITY/CLASS=SECURITY_CLASS コマンドを使用します。たとえば次のコマンドは,論理名テーブルに使用できるテンプレートを表示します。論理名テーブル・オブジェクトには,次の 3 つのテンプレートがあります。
$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE
.
.
.
Template: GROUP
Owner: [TTSY,SYSTEM]
Protection: (System: RWCD, Owner: R, Group: R, World:R)
Access Control List: [empty]
Template: JOB
Owner: [TTSY,SYSTEM]
Protection: (System: RWCD, Owner: RWCD, Group, World)
Access Control List: [empty]
Template: DEFAULT
Owner: [TTSY,SYSTEM]
Protection: (System: RW, Owner: RW, Group, World)
Access Control List: [empty]
セキュリティ・クラスのオブジェクトはすべて,他のオブジェクトと同じ方法で保護されます。このため,SHOW SECURITY によるセキュリティ・クラス・オブジェクトの表示は,そのオブジェクト自身のセキュリティ・プロファイルから始まります。次の表示は,セキュリティ・クラスにおける論理名テーブル・オブジェクトのプロファイルを示しています。オブジェクトはシステムに所有され,その保護コードにより,すべてのユーザ・カテゴリに読み込みアクセス権が許可されていますが,書き込みアクセス権が許可されているのはシステムと所有者のカテゴリのみです。
$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE
LOGICAL_NAME_TABLE object of class SECURITY_CLASS
Owner: [SYSTEM]
Protection: (System: RW, Owner: RW, Group: R, World: R)
Access Control List: [empty]
セキュリティ管理者と,セキュリティ・クラス・オブジェクトに対する制御アクセス権を持つユーザは,次のコマンドを使用して,指定されたテンプレートの要素を変更することができます。
SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name
次のコマンドは,デバイス・クラスの MAILBOX テンプレートを変更します。テンプレートの値を,S:RWPL,O:RWPL,G:RWPL,W:RWPL の保護から,グループ・アクセスとワールド・アクセスを許可しない保護に変更します。
$ SET SECURITY/CLASS=SECURITY_CLASS/TEMPLATE=MAILBOX -
_$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE
オペレーティング・システムは,この値をすべての新しいメールボックスに適用します。既存の各メールボックスの保護を変更するには,既存の各メールボックスに対して,明示的な SET SECURITY コマンドを入力します。次に例を示します。
$ SET SECURITY/CLASS=DEVICE -
_$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name
オペレーティング・システムは,セキュリティ・テンプレートに指定されているデフォルトのオブジェクト保護を保存するため,システムをリブートすると,リブート後に作成される全オブジェクトが,新しいデフォルトの保護で作成されるようになります。
注意
OpenVMS バージョン 7.2-1 およびそれ以前のバージョンでは,すべての擬似ターミナル (FT) デバイスの保護コードは,ドライバにより (S:RWLP,O:RWLP,G,W) に設定されていました。OpenVMS バージョン 7.3 以降では,この強制的な保護に設定されるのは,デバイス FTA0 のみです。これによりシステム管理者は,ブート・プロセスの後半で FTA0 デバイスの保護を変更できます。この新しい保護は,FTA0 から,以降作成されるすべての新しい FT デバイスによって継承されます (また,ACL などの,SECURITY クラスの DEVICE TERMINAL テンプレート・プロファイルに由来するその他の設定も継承されます)。
システム管理者は,FTA0 を手動で変更するか,SYSTARTUP_VMS.COM コマンド・プロシージャを変更することができます。次に例を示します。
$ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:
FTA0 のデバイス保護に変更を加えなければ,動作は OpenVMS バージョン 7.3 よりも前のバージョンと変わりません。つまり,FT 擬似ターミナル・デバイスを除き,ターミナルはすべて,TERMINAL テンプレート・プロファイルからデバイス保護などのセキュリティ特性を継承します。FTA 擬似ターミナル・デバイスはすべて,FTA0 から保護を継承し,その保護はデフォルトでは (S:RWLP,O:RWLP,G,W) に設定されています。ACL などその他の設定は,TERMINAL テンプレート・プロファイルから継承されます。これにより,既存のアプリケーションとの互換性が保証されます。
DCL の SHOW SECURITY コマンドを使用すると,サイトの値を持つ使用可能なテンプレートがすべて表示されます。第 5 章に,デフォルトのシステム値の一覧があります。
8.9 システムのデータと資源の追加保護
この節では,ユーザが使用できるデータと資源を制限する,追加の方法を説明します。
8.9.1 ソフトウェアの新規インストール時に必要な安全対策
新しいソフトウェアをインストールする際には,セキュリティに関するいくつかの点について対策を講じる必要があります。通常のセキュリティ上の安全対策を何らかの方法で損なったり,弱体化させるソフトウェアのインストールを認めないようにする必要があります。また,インストールするソフトウェアに特権を与えるべきかどうかも考慮する必要があります。この節では,新しいソフトウェアをインストールするときのセキュリティの側面を説明します。
8.9.1.1 潜在的に有害なプログラム
新しいソフトウェアには,システムに対する潜在的な危険のあるプログラムが含まれている可能性があります。トロイの木馬プログラムと呼ばれるこれらのプログラムは,損害を与えることを目的として作成されており,多くの場合,次の動作を行う機能が含まれています。
プログラムを実行する人物の特権を,プログラムの作成者に渡す
システムへの不正アクセスを許可する
システム・ファイルの保護を変更する
システムにパッチを適用する (オペレーティング・システムに特別なソフトウェアを追加する)
簡単に推測できるパスワードを検索するジョブを作成する
このタイプの侵入からシステムを守るには,必ず信頼できる販売元からソフトウェアを購入します。新しいユーザのトレーニングの際には,出所が定かでないソフトウェアの使用を避けることの重要性を強調します。
プログラムとディレクトリに対するもう 1 つの危険は,ウイルスと呼ばれるプログラムです。トロイの木馬のソフトウェアは,悪意のないユーザがトロイの木馬とは知らずにそのソフトウェアを使用することを利用するのに対して,ウイルスはユーザの協力を必要としません。ウイルスはファイル保護の欠陥を利用するプログラムで,システムに侵入し,コマンド・プロシージャと実行可能プログラムに変更を加えます。コマンド・プロシージャに変更を加えることで,ユーザのアクセス権と特権を利用して増殖できるようになります。
ウイルスは,パーソナル・コンピュータの環境と比較すると,OpenVMS 環境ではあまり大きな問題にはなりません。OpenVMS の保護機能と,環境の規模の大きさと多様性により,ウイルス攻撃が困難になっているためです。しかし,ソフトウェアとデータの共有が可能な環境の中で,ウイルス攻撃から安全な環境は存在しません。
このタイプのセキュリティ侵害の主なターゲットは,ユーザのログイン・コマンド・プロシージャです。一般的にログイン・コマンド・プロシージャには,定期的に実行され,簡単に変更が可能な DCL コマンドが含まれています。
ACL もターゲットになります。ユーザがアクセス特権を共有する設計になっているファイル保護では,このタイプのプログラムが,多数のユーザのプログラムを介して実行され,その過程で新しい特権が獲得される可能性があります。
このタイプのセキュリティ侵害からシステムを保護するには,ファイル保護を適切に設計することが非常に重要です。ターゲットになりやすいオブジェクトは,ユーザが変更できないようにします。たとえば,ログイン・コマンド・プロシージャが許可するのは,最大でもほかのユーザへの読み取りアクセス権までとなるようにファイル保護を設定します。また,ログイン・コマンド・プロシージャが含まれているディレクトリに対する書き込みアクセス権は,システム・カテゴリと所有者カテゴリのユーザにのみ許可するようにします。
損害の多くは,このようなプログラムが特権を持つターゲットのアカウントに到達すると発生するため,特権を持つユーザは,特にルート・ディレクトリ,実行可能ファイル,およびコマンド・プロシージャを慎重に保護する必要があります。トロイの木馬の攻撃を抑止するには,ユーザは,コマンド・プロシージャやイメージのソースを調べずに,特権アカウントでコマンド・プロシージャやイメージを実行するべきではありません。アプリケーション・イメージは,バイナリ・イメージが対応するソースを確実に反映するように,ソースからリビルドするべきです。
8.9.1.2 特権を与えてのプログラムのインストール
一部のソフトウェアは,実行に特権が必要です。ソフトウェアを実行する必要があると想定される全ユーザに対して特権を拡張したり,必要な特権を与えてプログラムをインストールすることができます。特権付きのソフトウェアをインストールすると,ユーザ個人が必要な特権を所有しているかどうかに関係なく,ユーザにソフトウェアの実行を許可することになります。結果として,プロセスがソフトウェアを実行する間,プロセスの特権が拡張されます。この方法にはいくつかのメリットがありますが,セキュリティに関わる危険性もあります。8.7 節では,これらの選択肢についてさらに詳しく説明しています。
8.9.2 システム・ファイルの保護
最も開放的なシステムであっても,システム・ソフトウェアの保護は必要です。通常,HP は適切な UIC 保護を設定した状態で,システム・プログラムおよびデータベースを出荷しています。しかし,何らかの理由でデフォルトの保護が不十分である場合,必要な SYSPRV 特権を持っていれば,第 4 章で概要を説明したテクニックを使用して,デフォルトの保護を変更できます。また,追加の保護が必要であると判断されるファイルには,ACL も追加できます。
OpenVMS のインストール中に次の DCL コマンドを使用することで,システム管理者のアカウントから,システム・ファイルの完全なリストを取得できます。
$ DIRECTORY/SECURITY/OUTPUT=SYSTEM_FILES.LIS SYS$SYSROOT:[*...]
このようなリストを作成し,参照用に保存しておくことをお勧めします。定期的にこれらの値を現在のシステム・ファイルの保護と比較して,改ざんがないことを確認します。DCL の DIRECTORY/SECURITY/OUTPUT コマンドと DIFFERENCES を使用すると,このようなチェックが簡単に行えます。
Alpha システムでは,読み取り専用の CD 配布メディアから,システム・ファイルとその保護のリストを入手できます。OpenVMS ソフトウェアでは,インストールが正常に行われれば,この保護コードのセットが得られるはずです。
VAX システムでのシステム・ファイルとその保護のリストについては,付録 B を参照してください。OpenVMS ソフトウェアでは,インストールが正常に行われれば,この保護コードのセットが得られるはずです。
表 8-4
に,ファイル保護の設定と表示に使用する DCL コマンドの要約を示します。これらのコマンドについては,『OpenVMS DCL ディクショナリ』で説明しています。
表 8-4: ファイル保護に使用する DCL コマンド
| コマンド | 機能 |
DIRECTORY/ACL |
ファイルの ACL を表示します |
DIRECTORY/OWNER |
ファイル所有者の UIC を表示します |
DIRECTORY/PROTECTION |
ファイルの保護コードを表示します |
DIRECTORY/SECURITY |
DIRECTORY/ACL,DIRECTORY/OWNER,および DIRECTORY/PROTECTION によって生成されるファイル情報を結合して表示します |
EDIT/ACL |
アクセス制御リスト・エディタ (ACL エディタ) を起動します |
SET PROTECTION/DEFAULT |
以降作成される全ファイルに適用されるデフォルトの保護を設定します |
SET SECURITY |
任意のオブジェクト (所有者,保護コード,および ACL) のセキュリティ・プロファイルを変更します |
SHOW SECURITY |
保護オブジェクトの所有権,UIC 保護コード,および ACL を表示します |
OpenVMS のインストール手順では,当初特権を与えずに MAIL.EXE をインストールします (MAIL.EXE は,その機能の実行に特権が必要ないためです)。OpenVMS オペレーティング・システムの以前のバージョンには,MAIL.EXE の再インストール時にシステム管理者が割り当てることのある一部の特権を MAIL.EXE がチェック,無視,付与,またはオーバーライドできるようにするメカニズムが含まれていました。これらの規制メカニズムは,予期しない状態や望ましくない状態を生み出すことがあったため,削除されました。
注意
特定の特権を与えて MAIL.EXE を再インストールする場合は,セキュリティ侵害の可能性を含め,発生しうる影響を注意深く検討する必要があります。たとえば,MAIL.EXE は Mail ユーティリティを起動するすべてのユーザにその特権を付与するため,該当ユーザは,SPAWN コマンドを指定して Mail 内からサブプロセスを作成すると,これらの特権を継承することになります。
すでに述べたように,HP はシステム・プログラムにデフォルトの保護を提供しています。しかし,特別な必要がある場合は,要件を満たすために ACL の能力を検討します。たとえば,ACL を使用して,コンパイラなどのシステム・プログラムの使用を制限できます。このような措置が必要になる要因として,パフォーマンスからライセンスの問題に至るまで,さまざまな要因が考えられます。
一部またはすべてのユーザがメディアを初期化できると不適切なケースがあるかどうかを考慮する必要もあります。そのようなケースがある場合は,システム・プログラム SYS$SYSTEM:INIT.EXE に対して ACL を適用できます。UIC ベースの保護コードにおいて,ワールド・カテゴリにアクセス権を付与しないようにします。その後,ファイルを対象に,特定のユーザにアクセス権を付与する ACL を作成します。
同様に,会社の特定の部署がソフトウェア製品に対してライセンス料を支払った場合は,その部署に限定してソフトウェアを使用可能にして,他の部署には使用できないようにすることができます。ワールド・カテゴリに,標準の UIC ベースの保護コードによってアクセス権が付与されていないことを確認し,ファイルの ACL に部署の識別子を介してアクセスを許可するエントリを作成します。
ACL 保護は,一部のユーザや保護サブシステムにアクセス権を限定するなど,アプリケーション・データベースの保護にも必要な場合があります。
8.9.3 DCL コマンドの使用の制限
ユーザによる DCL コマンドの使用を制御するには,いくつかの方法があります。たとえば,以下の方法があります。
SYS$SYSROOT:[SYSEXE] ディレクトリおよび SYS$SYSROOT:[SYSLIB] ディレクトリのシステム・プログラム・ファイルに,ACL を適用します。
AUTHORIZE の DISIMAGE フラグを設定することで,MCR コマンドまたは RUN コマンドの使用を禁止します。これによりユーザは,システム・イメージやユーザ記述イメージの実行,または外部コマンドとして定義されているイメージの実行を禁止されます。
DISIMAGE フラグは DCL コマンド言語インタプリタ (CLI) により適用されるため,DISIMAGE フラグの設定対象のアカウントは,DCL CLI にのみアクセスできることを確認する必要があります。DISIMAGE フラグは,AUTHORIZE の DEFCLI フラグと組み合わせて使用するか,制限付きアカウント内で使用します。アカウントに RESTRICTED フラグを設定すると,DEFCLI フラグが暗黙に設定されます。
DCL コマンドの定義を削除または変更し,DCL テーブルをリビルドします。コマンド定義の作成方法については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』で説明しています。変更したテーブルを指定するには,ユーザの UAF レコードで /CLITABLES 修飾子を使用します。また,ユーザが,指定したコマンド言語インタプリタ (CLI) とテーブルにのみログインできるように,/FLAGS=DEFCLI も指定します。元の DCL テーブルを不正アクセスから守るには,SYS$SYSROOT:[SYSEXE] ディレクトリおよび SYS$SYSROOT:[SYSLIB] ディレクトリのシステム・プログラム・ファイルに,ACL を適用します。特に,SYS$LIBRARY:DCLTABLES.EXE および SYS$SYSTEM:CDU.EXE を保護します。
ファイルの暗号化とは,データの内容を隠すために特定のアルゴリズムをデータに適用する処理を指します。復号は,逆の処理を行い,暗号化されている情報を変換して元の内容に戻します。自社開発ソフトウェアをメディアにコピーし,別のサイトに移動する必要がある場合には,ファイルを暗号化するとよいでしょう。メディア上のソフトウェアは,正しい復号コードがなければ利用できません。
ソフトウェアとハードウェアの両方で,さまざまなファイル暗号化システムが使用できます。お客様の国で使用できる製品の詳細については,HP のサポート・チャネルにお問い合わせください。
8.9.5 ディスクの保護
ディスク・スキャベンジングとは,パージまたは削除操作に続いて行われるファイル・ヘッダの削除の後で,データの磁気的な痕跡を読み取る処理です。ユーザがシステムからファイルを削除すると,ファイル・ヘッダのみが削除されます。データが上書きされるまで,そのデータはディスク・スキャベンジングのターゲットになる可能性があります。セキュリティの要件が中または高であるサイトは,この行為を考慮する必要があります。
全体のセキュリティ機能を確立した後,UIC ベースのボリューム保護を使用することで,重要な情報が格納されているディスクへのアクセスを制限します。ディスク・スキャベンジングはしばしば権限を持つユーザによって実行されるため,次の各節で説明する除去パターンとハイウォータ・マーク処理の実装を検討します。
8.9.5.1 除去テクニック
ディスク除去の実装には,いくつかの方法があります。
DELETE コマンドまたは PURGE コマンドに /ERASE 修飾子を追加すると,ユーザがファイルを削除またはパージする際に,システムによってそのファイル位置の全体がゼロの除去パターンで上書きされます。この修飾子を自発的に使用するようユーザを促すことも,システム・ログイン・コマンド・プロシージャ (通常は SYS$MANAGER:SYLOGIN.COM) に次のコマンドの定義を追加して自動的に修飾子が追加されるようにもできます。
DEL*ETE :== "DELETE/ERASE"PUR*GE :== "PURGE/ERASE"
ただし,どのユーザも DELETE コマンドまたは PURGE コマンドに /NOERASE 修飾子を追加することで,これらの定義を迂回できます。
削除時除去を確実に行うには,DCL の SET VOLUME/ERASE_ON_DELETE コマンドを使用して,ボリューム全体を対象にこの機能を有効にします。ファイルが削除されると,このコマンドにより,ボリューム上のどのファイルでもゼロの除去パターンによって上書きされます。
ボリュームの初期化時に,ボリュームを完全に除去し,ボリュームで削除時除去を有効にするには,DCL の INITIALIZE/ERASE コマンドを使用します。
デフォルトでは,削除時除去が有効である場合,オペレーティング・システムは,領域に対する単一の上書き操作時に適用されるデフォルトのゼロによるデータ・セキュリティ除去 (DSE) パターンを書き込みます。デフォルトのパターンであるゼロや (複数回の除去ではなく) 1 回の除去では要件に適さないと思われる場合は,$ERAPAT (Get Security Erase Pattern) システム・サービスを使用して,カスタマイズされた除去パターンを書き込むことができます。詳細については,『HP OpenVMS System Services Reference Manual』にある $ERAPAT の説明を参照してください。
セキュリティ要件のレベルが高いサイトでは,固定パターンよりもランダム・パターンの方が適しています。わずかに残る磁気の痕跡を検出して使用する技術が,すでに利用できるようになっているためです。そのため,ディスクが取り外され,このような特別な分析装置を使用して読み取られる危険性が十分あると結論付けられる場合は,除去パターンを複数回再書き込まなければならない場合があります。データ・セキュリティ除去パターンをニーズに合うようカスタマイズする方法については,SYS$EXAMPLES:DOD_ERAPAT.MAR ファイルに記載されている情報から学習できます。
除去パターンは,セキュリティ要件が最も厳しいディスクにのみ使用します。除去は時間を要し,システムのパフォーマンスに影響するためです。
8.9.5.2 ハイウォータ・マーク処理による防止
ハイウォータ・マーク処理とは,各ファイルが書き込まれた位置の上限を追跡し,ユーザがその地点を超えてデータを読み取ろうとするのを禁止するテクニックを指します。
オペレーティング・システムは,さまざまなテキスト・エディタ,コンパイラ,およびリンカから出力されるファイル (つまり,プロセスが書き込む大部分のファイル) のセットをはじめとするすべての順編成,排他的アクセス・ファイルに対し,真のハイウォータ・マーク処理を実装します。ファイル・ヘッダにあるハイウォータ・マークは,ファイルの論理的な終端マークが更新された時点 (通常はファイルが閉じられる時点) で更新されます。
共有ファイル (索引編成と順編成の両方) では,オペレーティング・システムは割り当て時除去の原則を使用して,真のハイウォータ・マーク処理に近い結果を実現します。ファイルが作成または拡張されようとする時点で,システムはどれだけのディスク領域 (ファイルの範囲) が必要であるかを判断し,書き込み用に割り当てられる領域 (範囲) に,ゼロのセキュリティ除去パターンを適用します。その後,ファイルは,そのファイルのために除去された領域に書き込まれます。したがって,ユーザが (範囲全体を含め) 該当ファイルへのアクセス権を取得し,ファイルが書き込まれた領域を超える領域を読み込もうとしても,読み込めるのはデータ・セキュリティ除去パターンのみです。
デフォルトでは,オペレーティング・システムはすべてのボリュームに対してハイウォータ・マーク処理を有効にします。ハイウォータ・マーク処理 は,ディスク・スキャベンジングの試みに対する抑止力になります。ただし,ハイウォータ・マーク処理は余分に入出力が必要となるため,システム・パフォーマンスに影響を与えます。
DCL の SET VOLUME/NOHIGHWATER_MARKING コマンドを指定することで,ボリュームごとにハイウォータ・マーク処理と割り当て時除去を無効にすることができます。
8.9.5.3 防止テクニックの要約
セキュリティ管理者は,次の制御を適用することによって,ディスク・スキャベンジングを阻止することができます。
厳重な物理的セキュリティを適用します。最も重要な情報が格納されているディスクに関しては特に厳重にします。
UIC ベースの保護を利用して,厳重なボリューム保護を適用します。
ユーザの自発行為またはボリュームに対する強制適用によって,重要なファイルのパージまたは削除時の /ERASE 修飾子の使用を促します。
最も重要なディスクでは,デフォルトでハイウォータ・マーク処理を行うようにします。
ファイル,ディレクトリ,およびディスクのコピーを作成することで,データを喪失や破損から守ることができます。問題が発生した場合は,バックアップ・コピーを復元して,作業を継続することができます。メディアの安全な保管と,メディアへのアクセスの管理は,このプロセスの重要な要素です。バックアップ・メディアは,対象サイト以外の場所に保管するのが理想的です。
8.9.6.1 ディスクのバックアップ
効果的なバックアップ・スケジュールを立てることが,データの保護にとって非常に重要です。バックアップを定期的に行うことで,ファイルの誤削除や破損による喪失を防ぐことができます。
バックアップの実施とバックアップ・スケジュールの設定の詳細については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。バックアップ・ユーティリティ (BACKUP) ユーティリティは,セキュリティ・ポリシーを実装しないことに注意してください。セキュリティ管理者がバックアップ・ユーティリティに明示的に指示する必要があります。バックアップ・ユーティリティは,オペレータのセキュリティ・プロファイルを使用して実行されます。多くの場合,そのセキュリティ・プロファイルは特権付きです。
8.9.6.2 バックアップ・セーブ・セットの保護
バックアップ・セーブ・セットへのアクセスの制限は,システム・セキュリティの重要な要素です。ファイル・システムは,バックアップ・セーブ・セットがディスクまたは磁気テープのどちらに保存されていても,バックアップ・セーブ・セットを単一のファイルとして扱います。したがって,セーブ・セットにアクセスできるユーザであれば誰でもセーブ・セットの任意のファイルを読み込むことができます。BACKUP は,個別ファイルの保護をチェックしません。
システム・セキュリティを維持するには,セーブ・セットを適切に保護することが非常に重要になります。出力セーブ・セット修飾子の /BY_OWNER および /PROTECTION を使用して,ディスク上のセーブ・セットと,磁気テープ・ボリュームに,制限付きの保護を割り当てます。保護が十分であれば,非特権ユーザがセーブ・セット・ボリュームをマウントしたり,セーブ・セットからファイルを読み込むことを防止できます。施錠されたキャビネットにバックアップ・メディアを保管することで,オフ・ラインで保管されるセーブ・セットについても,物理的なセキュリティ対策を講じる必要があります。
セーブ・セットを Files--11 ディスクや順編成ディスクに書き込み,/PROTECTION 修飾子は指定しない場合,BACKUP は,セーブ・セットにデフォルトのプロセス保護を適用します。/PROTECTION を指定した場合,未指定の保護カテゴリのデフォルトは,すべてデフォルトのプロセス保護になります。
保護情報は,磁気テープのボリューム・ヘッダ・レコードに書き込まれ,そのテープに保存されるすべてのセーブ・セットに適用されます。そのため,出力セーブ・セット修飾子 /BY_OWNER および /PROTECTION が磁気テープ・セーブ・セットで有効であるのは,出力セーブ・セット修飾子 /REWIND を指定した場合のみです。この修飾子によりテープは,先頭への巻き戻し,ボリューム・ヘッダ・レコードへの保護データの書き込み,テープの初期化を行うことができます。/PROTECTION を指定した場合は,未指定の保護カテゴリのデフォルトは,すべてデフォルトのプロセス保護になります。/PROTECTION および /BY_OWNER 修飾子と合わせて /REWIND を指定しなかった場合,磁気テープは既存の保護を保持します。ただし,/REWIND のみを指定すると,保護がまったくない磁気テープになってしまいます。
次の例に,ディレクトリをテープにバックアップする方法を示します。
$ BACKUP
_FROM: [PAYROLL]
_TO: MFA2:KNOX.BCK/LABEL=BANK01 -
_$ /REWIND/BY_OWNER_UIC=[030,003] -
_$ /TAPE_EXPIRATION=15-JAN-2001 -
_$ /PROTECTION=(S:RWE,O:RWED,G:RE,W)
ディレクトリ [PAYROLL] の内容が,磁気テープ・ドライブ MFA2 のファイル KNOX.BCK にコピーされます。出力セーブ・セット修飾子 /LABEL は,そのテープのラベル BANK01 を指定しています。
出力セーブ・セット修飾子 /BY_OWNER は,セーブ・セットに [030,003] という所有者 UIC を割り当てています。
出力セーブ・セット修飾子 /TAPE_EXPIRATION は,テープに 2001 年 1 月 15 日の期限を割り当てています。
出力セーブ・セット修飾子 /PROTECTION は,ボリュームの所有者に,読み込みアクセス権,書き込みアクセス権,実行アクセス権,および削除アクセス権を割り当てています。システム・ユーザには読み込みアクセス権,書き込みアクセス権,実行アクセス権が割り当てられ,グループ・ユーザには読み込みアクセス権と実行アクセス権が割り当てられ,ワールド・ユーザにアクセス権は割り当てられていません。
8.9.6.3 バックアップ・セーブ・セットからのファイルの取り出し
セーブ・セットにアクセスできるユーザであれば誰でもセーブ・セットの任意のファイルを読み込むことができます。バックアップ・メディアのコピーをユーザには絶対に渡さないでください。悪意のあるユーザがテープやディスクからファイルを復元し,システムのセキュリティを危険にさらす可能性があるためです。
非特権ユーザが特定のファイルを復元する必要がある場合も,セーブ・セットが格納されているボリュームを貸さないでください。ボリューム上の全ファイルへのアクセス権を渡してしまう可能性があるためです。特定のファイルを復元する最も安全な方法は,次の例のように,個別にファイルを復元する方法です。
$ BACKUP MTA0:JULY.BCK/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT -
_$ [*...]/BY_OWNER=ORIGINAL
選択されたファイルは,元のディレクトリ,所有権,および保護とともに復元されます。この方法では,ファイル・システムによって,ユーザにファイル・アクセスが許可されているかどうかが判定されます。
8.9.7 ターミナルの保護
以降の節では,ターミナルの使用制限に利用できる制御を説明します。
8.9.7.1 ターミナルの使用制限
オペレーティング・システムは,デバイス・オブジェクト・クラス・テンプレート TERMINAL を使用して,SYSTEM アカウントのみがアクセスできるようにターミナルを設定します。ユーザがログインすると,オペレーティング・システムは,所有権をシステム UIC から現在のプロセスの UIC に移します。
特定のターミナルへのログインを制限するには,次の方法があります。
システム・パスワードを割り当てます。
ターミナルを /NOTYPE_AHEAD に設定し,ログインを不可能にします。
システム・パスワードを適用することで,対象ターミナルの使用がシステム・パスワードを知っているユーザに限定されます。
8.9.7.2 アプリケーション・ターミナルなどのデバイスの制限
ターミナルを,アプリケーション・ターミナルとして一部のユーザがアクセスできるようにするには,対象デバイスのセキュリティ特性の一部または全部を変更します。(適切な保護コードを持つ) 特定のターミナルを対象に,コマンド・プロシージャ SYS$MANAGER:SYSTARTUP_VMS.COM に,DCL の SET SECURITY/CLASS=DEVICE コマンドを含めることができます。この DCL コマンドは,ファイル構造ではないすべてのデバイスへのアクセスを制限できます。また,デバイスに ACL を適用して,ユーザ・アクセスを制限することもできます。
8.9.7.3 モデム用のターミナル回線の設定
モデム用のターミナル回線を設定する場合,会話型の使用が想定されているモデム装置が接続されている回線では,/COMMSYNC 修飾子を,DCL の SET TERMINAL コマンド (または TTDRIVER インタフェースの TT$M_COMMSYNC 属性) に対して絶対に設定しないでください。
この修飾子は,モデム電話回線に障害が発生した場合にターミナル回線からユーザ・プロセスを切断する,モデム・ターミナル属性を無効にします。/COMMSYNCH 修飾子が有効になっていると,ターミナル回線に対する次の着信が,前のユーザのプロセスに接続される可能性があります。/COMMSYNC 修飾子は,モデム信号をフロー制御として使用することにより,非同期プリンタなどのデバイスのターミナル・ポートへの接続を可能にすることを目的としています。