Page History

概要

情報を共有する場合、セキュリティは重要な問題です。Yellowfinを導入する際には、要求されるセキュリティレベルについて詳細な分析が行われるべきです。Yellowfinには、共有される情報の安全性を保つためのセキュリティ機構が複数組み込まれています。必要とされるセキュリティレベルに合わせてこれらを組み合わせて使用します。使用可能なセキュリティ機構は次のとおりです。

• アクセス権と機能
• レポートカテゴリー
• ソースシステムへのアクセス管理
• ビューのアクセス管理
• アクセスフィルター/値ベースのフィルターの追加

このセクションでは、Yellowfinで使用できるセキュリティフレームワークについて解説します。解説は粗いセキュリティレベルから始まり順に細かなレベルへと進みます。たとえば、ロールは最も粗いレベルのセキュリティで管理も簡単です。逆にカラムレベルのセキュリティは詳細な設定が可能ですが、たくさんのユーザーが使うシステムを管理する場合には複雑に過ぎるかもしれません。

アクセス権と機能

Yellowfinのユーザー管理は、ユーザーロールを基礎にデザインされています。これは、複数のユーザーがアプリケーションへのアクセスのために定義済みのロールを共有することを意味します。個別のユーザーにユニークなセキュリティプロフィールを設ける必要はありません。

ロールは、利用可能なセキュリティ機能のコレクションです。各々のユーザーにはなんらかのロールが割り当てられます。たとえばある人物をレポート作成者にするには2つの方法があります：

1. その人のロールを変更する：その人にアプリケーションにアクセスできるロールを割り当てます。
2. その人に割り当てられているロールの設定を変更する：そのロールを共有するすべてのユーザーのアクセス権をアプリケーションにアクセスできるように変更します。

ユーザーがログオンすると、システムはその人がアプリケーションに登録されているか、そしてどんなロールを割り当てられているかをチェックします。そしてそのロールに設定されたアクセス権に基づき、そのロールがアクセス権を持つ機能だけを表示するようユーザーインターフェースがダイナミックに構築されます。

詳細については、ロール管理を参照してください。

Expand
title 例
ログオンしたユーザーのロールがダッシュボードへのアクセス権を持たない場合、その人にはレポート一覧のページが表示されることになります。ダッシュボードにアクセス権を持つユーザーには、ダッシュボードページが表示されます。 主な用途 アクセスを特定の機能（たとえばレポートを作成する）に制限したい場合に使用します。 使うべきでない場合 ロールには情報やデータに対するアクセスを制限する効果はありません。 利点 すべてのユーザーに対する設定や更新が簡単です。 ヒント 設定するロールの種類は極力少なくしましょう。ロールが増えるに従って管理が煩雑になります。通常、ユーザー一人につき1つのロールを割り当てるようにしてください。Yellowfinには一人に複数のロールを割り当てる能力がありますが、それはビジネスユーザーに混乱をもたらしがちです。

レポートカテゴリー

すべてのレポートは、コンテントアクセス機能の設定によるカテゴリー構造とセキュリティによって管理されています。

レポートのセキュリティは、個々のアイテムレベルではなく、カテゴリーとサブカテゴリーのレベルで管理されます。これはレポートの作成をより簡便にするためです。

詳細については、コンテンツカテゴリーを参照してください。

Expand
title 例
新しいレポートを作成するたびに誰がそれを見ることができるのか設定しなければならないのは煩雑です。この機能により、新規作成されたレポートはそのセキュリティを属するカテゴリーとサブカテゴリーから継承します。 主な用途 レポートの参照を部署などのビジネスグループによって制限する場合に有効です。Writeレベルのセキュリティが設定されているビューで、カテゴリーにアクセス権を与えるということは、それを読む権限しか持たないカテゴリーに対してレポートを公表する権限を与えることになります。 使うべきでない場合 ユーザーがあるビューに対してレポートを書くことができるのに（これはすなわちそのビューのセキュリティが無効であることを意味します）、そのビューに論理的に適合するカテゴリーを見ることができないような場合、カテゴリーを使ったセキュリティに意味はありません。 たとえば、カテゴリーが人事報告であり、ビューは人事データベースへのビューだとします。ビューのセキュリティが無効で、ユーザーがレポートを書くことができる場合、ユーザーはレポートビルダーを通して元のデータにアクセスできるわけですから、カテゴリーに設定されたセキュリティは無意味です。また、すべてのビューに対してReadレベルのアクセス権しか設定しないのであれば、カテゴリーセキュリティは必要ありません。 利点 カテゴリーセキュリティは、閲覧のみのユーザーを特定分野から除外するのに有効です。 ヒント カテゴリーはユーザーが直観的に理解できるように作成してください。たとえば「人事専用」というカテゴリーは、経営幹部が人事のために利用するためだけに使われます。カテゴリーにレポートを公開するユーザーは、そのカテゴリーのセキュリティについて十分知っていなければなりません。

ソースシステムへのアクセス管理

Yellowfinでソースシステムとの接続を設定する際、どのユーザーがソースに対してSQLクエリーを発行できるかだけでなく、どのユーザーがそのソースに対してビューを作成できるかも設定することができます。

ソースシステムのセキュリティに関する原則は、それがレポート作成者のソースに対するビューの作成をコントロールするためのものだということです。ユーザーがソースシステムに対してレポートを作成でき、それによって無制限にデータにアクセスできるのでは、このプロセスは素通しもいいところです。

詳細については、データソース接続を参照してください

Expand
title 例
人事管理システムがソースシステムとしてセットアップされているとして、ソースのセキュリティが無効な場合、ビューを作成できる権限をもつユーザー全員が、従業員名簿を含むすべてのテーブルを閲覧できてしまいます。人事システムにセキュリティを設定することで、許可されたユーザーだけがこのソースに対してビューを作成、管理することができるようになります。 主な用途 複数のビュー管理者がいる場合：管理者ごとにアクセス可能なソースデータベースを指定できます。レポート作成のためにソースに対するSQLクエリーの発行を許可しており、かつデリケートなデータが含まれる場合にはお使いください。 使うべきでない場合 レポート作成のための「Drag & Drop Report Writer」の動作を制限するために使うべきではありません。 利点 選ばれた数人のユーザーを管理するのに便利です。 ヒント ビューの管理権限を持つユーザーの数を制限してください。特に彼らに同じソースシステムを編集させる場合これは重要です。管理者が複数存在すると、ビューの管理時に競合の問題が発生することがあります。 注意：稼働中のYellowfinでレポート作成者が1人しかおらず、ソースにSQLクエリーを発行できるユーザーもいない場合には、ソースシステムのセキュリティを無効に設定しておいてもかまいません。

ビューのアクセス管理

レポートを作成し、どんなレポートでも書くことのできるビューへのアクセス権限を持つユーザーに対するセキュリティは、ビューセキュリティによって設定されます。

レポートを作成、あるいは編集する場合、ユーザーはどのフィールドが利用可能かビューレコードに問い合わせます。ここでのセキュリティチェックはアクセス先のビューにセキュリティが設定されているかどうかを調べることです。もし設定されていれば、ユーザーにはアクセス権限があると見なされます。

ビューに関するセキュリティは、それに保存されるデータへのアクセスを管理する観点から、最も厳しいものになっています。編集アクセス権をコントロールできるだけでなく、どのユーザーが特定のビューから作成されたレポートを読むことができるかまでコントロールすることが可能です。

詳細については、ビューオプションを参照してください

Expand
title 例
たとえば財務に関するビューが作成され、財務部だけが、そのビューを使ったレポートの作成を許されたとします。この場合、ビューは安全であると定義され、財務部に属するユーザーは編集アクセス権を持つアクセスリストに加えられます。 主な用途 特定のビューを使ってレポート作成を行うユーザーを制限したい場合には使うべきです。特定のビューによって作成されたレポートについて、読むことはできるものの作成する権限を持たないユーザーを設定したい場合にも使用します。 使うべきでない場合 ビューのレポートが少数のユーザーによって作成され、より広いコミュニティに公開されるような場合には、READレベルセキュリティは使わないほうがいいでしょう。代わりにカテゴリーセキュリティを使ってください。 たとえば、ビューがデリケートなデータを含む場合でも、このビューを使って（そのデータを含まない）レポートを作成・配信しなければならないことがあります 。カテゴリーとビューの両方でアクセスを制限するよりは、単にレポートが所属するカテゴリーでそれを行う方が簡便です。 デリケートなデータがなければ、無用なセキュリティをかけるべきではありません。 利点 EDITレベルセキュリティを管理するのが簡単です。カテゴリーセキュリティと一緒にREADレベルのセキュリティを使うことは混乱の原因になりがちです。 ヒント そのビューに対して誰がレポートを作成しているか、またそのレポートが誰に向けて作成されているのかを把握する必要がある場合には、これを使うのが最高の選択肢でしょう。また、レポートが広く公表されるものならば、参照に制限をかけるべきではありません。

カラムアクセスと制限

時として、一般的な使用のために作成されたビューにデリケートなカラムが混在している場合があります。たとえば、人事管理に関するビューには、当然給料のカラムが含まれます。しかしながら、これは誰にでも見られていいものではありません。

このような場合、次のような2種類の対策が考えられます。

1. ビューのコピーを作成して、給料カラムをそれから除外します。ビューにデリケートなデータが含まれないことを示すために、新しい名前でこのビューを保存してください。
2. Yellowfinには、特定のカラムだけに制限をかける機能があります。あるカラムにこの制限をかければ、そのカラムは許可されたユーザー以外には参照できなくなります。
   注意：カラムへの制限は、グローバルに適用されます。1つのビューに含まれる複数のカラムに対して、異なるユーザーへのアクセス許可を指定することはできません。
   レポートを作成するとき、アクセス権をもつユーザーだけがそのカラムを見ることができます。有効なレポートが実行されると、制限がかけられたカラムがそのレポートへのアクセス権を持つすべてのユーザーに表示されます。

詳細については、フィールドアクセスと使用方法を参照してください

Expand
title 例
主な用途 そのビューが多くのユーザーが利用できるべきものであり、デリケートなカラムへのアクセスを許可するユーザーがごく少数で済む場合にお使いください。 使うべきでない場合 そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。 利点 ビューに含まれるカラムに対して個別にセキュリティを設定することができます。 ヒント 管理の観点から言えばメンテナンスが難しいセキュリティオプションです。できるだけ他の方法を検討してください。ビューへのアクセス権をもつユーザーだけが、カラムレベルのアクセス権を持つことができます。

アクセスフィルター/値ベースのフィルターの追加

時として、一般的な使用のために作成されたビューから、ユーザーの組織内での役職（たとえばコストセンターの管理者など）に関連したデータのみにアクセスさせたい場合があります。そのような場合には、アクセス権、あるいは値に基づくフィルターを作成することができます。

これは、たとえばコストセンターとそのユーザーだけがその接続を使えるようソース接続ウイザードをアップデートすることによって実現されます。次にそのビューでソースフィルターと関連する特定のカラムを指定します。つまりビューのどのカラムがコストセンターに関わるカラムであるかを明示するわけです。

レポート作成にあたって、このコストセンターフィルターがアクセス権のフィルターとして働くことを指定します。この場合、レポート閲覧者が所有する権限が、クエリーに関わるフィルターとして渡されます。こうして、定められたアクセス権限をもつユーザーだけが、そのレポートでデータを閲覧することができます。

詳細については、ソースアクセスフィルターを参照してください

Expand
title 例
主な用途 そのビューが多くのユーザーが利用できるべきものであり、かつアクセスをデータとユーザーの関係（たとえばコストセンターとその管理者など）に基づいて制限したい場合にお使いください。 このメカニズムは、個人向けのレポートを作成するような場合非常に便利です。値に基づくフィルターを使えば、1つのレポートを多くのユーザー向けに公表することができます。各々のユーザーは同じレポートから自分の権限に見合ったデータだけを閲覧することになります。 使うべきでない場合 そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。 利点 ビューに含まれるデータのうち、関連のあるデータだけ表示するように制限することができます。 ヒント これは、管理者から見てメンテナンスのしやすいオプションです。 このメカニズムによって、自分がビューの中の特定のデータのみを参照できるということを知っているすべてのユーザーに適切なアクセス権を与えることができます。