| Wiki Markup |
|---|
{anchor:top}
{toc: class=contents}
h2. 概要
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
情報を共有する場合、セキュリティは重要な問題です。Yellowfinを導入する際には、要求されるセキュリティレベルについて詳細な分析が行われるべきです。Yellowfinには、共有される情報の安全性を保つためのセキュリティ機構が複数組み込まれています。必要とされるセキュリティレベルに合わせてこれらを組み合わせて使用します。使用可能なセキュリティ機構は次のとおりです。
* [アクセス権と機能|セキュリティフレームワーク#Access Roles & Functions]
* [レポートカテゴリー|セキュリティフレームワーク#Report Categories]
* [ソースシステムへのアクセス管理|セキュリティフレームワーク#Source System Access Management]
* [ビューのアクセス管理|セキュリティフレームワーク#View Access Management]
* [アクセスフィルター/値ベースフィルターの追加|セキュリティフレームワーク#Access / Value Based Filters]
このセクションでは、Yellowfinで使用できるセキュリティフレームワークについて解説します。解説は粗いセキュリティレベルから始まり順に細かなレベルへと進みます。たとえば、ロールは最も粗いレベルのセキュリティで管理も簡単です。逆にカラムレベルのセキュリティは詳細な設定が可能ですが、たくさんのユーザーが使うシステムを管理する場合には複雑に過ぎるかもしれません。
h2. アクセス権と機能
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
Yellowfinのユーザー管理は、ユーザーロールを基礎にデザインされています。これは、複数のユーザーがアプリケーションへのアクセスのために定義済みのロールを共有することを意味します。個別のユーザーにユニークなセキュリティプロフィールを設ける必要はありません。
ロールは、利用可能なセキュリティ機能のコレクションです。各々のユーザーにはなんらかのロールが割り当てられます。たとえばある人物をレポート作成者にするには2つの方法があります：
# その人のロールを変更する：その人にアプリケーションにアクセスできるロールを割り当てます。
# その人に割り当てられているロールの設定を変更する：そのロールを共有するすべてのユーザーのアクセス権をアプリケーションにアクセスできるように変更します。
ユーザーがログオンすると、システムはその人がアプリケーションに登録されているか、そしてどんなロールを割り当てられているかをチェックします。そしてそのロールに設定されたアクセス権に基づき、そのロールがアクセス権を持つ機能だけを表示するようユーザーインターフェースがダイナミックに構築されます。
bq. 詳細については、[ロール管理]を参照してください。
h3. {expand:title=例}
ログオンしたユーザーのロールがダッシュボードへのアクセス権を持たない場合、その人にはレポート一覧のページが表示されることになります。ダッシュボードにアクセス権を持つユーザーには、ダッシュボードページが表示されます。\
| {*}主な用途{*} \| アクセスを特定の機能（たとえばレポートを作成する）に制限したい場合に使用します。 \|\
| {*}使うべきでない場合{*} \| ロールには情報やデータに対するアクセスを制限する効果はありません。\ |\
| {*}利点{*} \| すべてのユーザーに対する設定や更新が簡単です。\ |\
| {*}ヒント{*} \|設定するロールの種類は極力少なくしましょう。ロールが増えるに従って管理が煩雑になります。通常、ユーザー一人につき1つのロールを割り当てるようにしてください。Yellowfinには一人に複数のロールを割り当てる能力がありますが、それはビジネスユーザーに混乱をもたらしがちです。\ |
{expand}
h2. レポートカテゴリー
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
すべてのレポートは、コンテントアクセス機能の設定によるカテゴリー構造とセキュリティによって管理されています。
レポートのセキュリティは、個々のアイテムレベルではなく、カテゴリーとサブカテゴリーのレベルで管理されます。これはレポートの作成をより簡便にするためです。
bq. 詳細については、[レポートカテゴライズ]を参照してください。
h3. {expand:title=例}
新しいレポートを作成するたびに誰がそれを見ることができるのか設定しなければならないのは煩雑です。この機能により、新規作成されたレポートはそのセキュリティを属するカテゴリーとサブカテゴリーから継承します。\
| {*}主な用途{*} \| レポートの参照を部署などのビジネスグループによって制限する場合に有効です。 Writeレベルのセキュリティが設定されているビューで、カテゴリーにアクセス権を与えるということは、それを読む権限しか持たないカテゴリーに対してレポートを公表する権限を与えることになります。 \|\
| {*}使うべきでない場合{*} \| ユーザーがあるビューに対してレポートを書くことができるのに（これはすなわちそのビューのセキュリティが無効であることを意味します）、そのビューに論理的に適合するカテゴリーを見ることができないような場合、カテゴリーを使ったセキュリティに意味はありません。
たとえば、カテゴリーが人事報告であり、ビューは人事データベースへのビューだとします。 ビューのセキュリティが無効で、ユーザーがレポートを書くことができる場合、ユーザーはレポートビルダーを通して元のデータにアクセスできるわけですから、カテゴリーに設定されたセキュリティは無意味です。
また、すべてのビューに対してReadレベルのアクセス権しか設定しないのであれば、カテゴリーセキュリティは必要ありません。 \|\
| {*}利点{*} \| カテゴリーセキュリティは、閲覧のみのユーザーを特定分野から除外するのに有効です。\ |\
| {*}ヒント{*} \| カテゴリーはユーザーが直観的に理解できるように作成してください。 たとえば「人事専用」というカテゴリーは、経営幹部が人事のために利用するためだけに使われます。 カテゴリーにレポートを公開するユーザーは、そのカテゴリーのセキュリティについて十分知っていなければなりません。 \|
{expand}
h2. ソースシステムへのアクセス管理
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
Yellowfinでソースシステムとの接続を設定する際、どのユーザーがソースに対してSQLクエリーを発行できるかだけでなく、どのユーザーがそのソースに対してビューを作成できるかも設定することができます。
ソースシステムのセキュリティに関する原則は、それがレポート作成者のソースに対するビューの作成をコントロールするためのものだということです。ユーザーがソースシステムに対してレポートを作成でき、それによって無制限にデータにアクセスできるのでは、このプロセスは素通しもいいところです。
bq. 詳細については、[データソース接続]を参照してください。
h3. {expand:title=例}
人事管理システムがソースシステムとしてセットアップされているとして、ソースのセキュリティが無効な場合、ビューを作成できる権限をもつユーザー全員が、従業員名簿を含むすべてのテーブルを閲覧できてしまいます。人事システムにセキュリティを設定することで、許可されたユーザーだけがこのソースに対してビューを作成、管理することができるようになります。\
| {*}主な用途{*} \| 複数のビュー管理者がいる場合：管理者ごとにアクセス可能なソースデータベースを指定できます。 レポート作成のためにソースに対するSQLクエリーの発行を許可しており、かつデリケートなデータが含まれる場合にはお使いください。\ |\
| {*}使うべきでない場合{*} \| レポート作成のための「Drag & Drop Report Writer」の動作を制限するために使うべきではありません。 \|\
| {*}利点{*} \|選ばれた数人のユーザーを管理するのに便利です。 \|\
| {*}ヒント{*} \| ビューの管理権限を持つユーザーの数を制限してください。特に彼らに同じソースシステムを編集させる場合これは重要です。 管理者が複数存在すると、ビューの管理時に競合の問題が発生することがあります。 \|
{color:#c00000}注意：{color}稼働中のYellowfinでレポート作成者が1人しかおらず、ソースにSQLクエリーを発行できるユーザーもいない場合には、ソースシステムのセキュリティを無効に設定しておいてもかまいません。
{expand}
h2. ビューのアクセス管理
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
レポートを作成し、どんなレポートでも書くことのできるビューへのアクセス権限を持つユーザーに対するセキュリティは、ビューセキュリティによって設定されます。
レポートを作成、あるいは編集する場合、ユーザーはどのフィールドが利用可能かビューレコードに問い合わせます。ここでのセキュリティチェックはアクセス先のビューにセキュリティが設定されているかどうかを調べることです。もし設定されていれば、ユーザーにはアクセス権限があると見なされます。
ビューに関するセキュリティは、それに保存されるデータへのアクセスを管理する観点から、最も厳しいものになっています。編集アクセス権をコントロールできるだけでなく、どのユーザーが特定のビューから作成されたレポートを読むことができるかまでコントロールすることが可能です。
bq. 詳細については、[ビューオプション]を参照してください。
h3. {expand:title=例}
たとえば財務に関するビューが作成され、財務部だけが、そのビューを使ったレポートの作成を許されたとします。この場合、ビューは安全であると定義され、財務部に属するユーザーは編集アクセス権を持つアクセスリストに加えられます。\
| {*}主な用途{*} \| 特定のビューを使ってレポート作成を行うユーザーを制限したい場合には使うべきです。 特定のビューによって作成されたレポートについて、読むことはできるものの作成する権限を持たないユーザーを設定したい場合にも使用します。\ |\
| {*}使うべきでない場合{*} \|<!-- ビューのレポートが少数のユーザーによって作成され、より広いコミュニティに公開されるような場合には、READレベルセキュリティは使わないほうがいいでしょう。代わりにカテゴリーセキュリティを使ってください。
/*たとえば、ビューがデリケートなデータを含む場合でも、このビューを使って（そのデータを含まない）レポートを作成・配信しなければならないことがあります Style。
Definitionsカテゴリーとビューの両方でアクセスを制限するよりは、単にレポートが所属するカテゴリーでそれを行う方が簡便です。
*/ table.MsoNormalTable {mso-style-name:標準の表; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0mm 5.4pt 0mm 5.4pt; mso-para-margin:0mm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";} --\|\| *利点* \| Easy to maintain for EDIT level security - can become complicated if using READ level security in conjunction with category security. \|\| *ヒント* \| If the view is sensitive determine who the users writing reports against the view are and for whom they are writing reports. Use this to determine the best security strategy for the view. If the reports are for a wide distribution view security for read access might not be appropriate. \|デリケートなデータがなければ、無用なセキュリティをかけるべきではありません。 |
| {*}利点{*} | EDITレベルセキュリティを管理するのが簡単です。カテゴリーセキュリティと一緒にREADレベルのセキュリティを使うことは混乱の原因になりがちです。 |
| {*}ヒント{*} | そのビューに対して誰がレポートを作成しているか、またそのレポートが誰に向けて作成されているのかを把握する必要がある場合には、これを使うのが最高の選択肢でしょう。また、レポートが広く公表されるものならば、参照に制限をかけるべきではありません。 |
{expand}
h2. Column Access & Restrictions
カラムアクセスと制限
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
In時として、一般的な使用のために作成されたビューにデリケートなカラムが混在している場合があります。たとえば、人事管理に関するビューには、当然給料のカラムが含まれます。しかしながら、これは誰にでも見られていいものではありません。
some
cases a view might be created that is designed for general use but some columns within that view are highly sensitive. For example the salary column in the human resources view holds data that is not for general consumption.
In this case you have two options.
# Create a copy of the view and exclude the salary column from this instance. Save the view with a new name to indicate that the view is free of sensitive data.
# Alternatively Yellowfin provides you with the opportunity to define the columns as restricted columns. Once this has been done an additional layer of security needs to be defined, which allows certain users access to the restricted columns of the selected view.
このような場合、次のような2種類の対策が考えられます。
# ビューのコピーを作成して、給料カラムをそれから除外します。ビューにデリケートなデータが含まれないことを示すために、新しい名前でこのビューを保存してください。
# Yellowfinには、特定のカラムだけに制限をかける機能があります。あるカラムにこの制限をかければ、そのカラムは許可されたユーザー以外には参照できなくなります。
{color:#c00000}{*}Note:注意：*{color} security to restricted columns is globally defined. You cannot specify different users for separate restricted columns within the view.
Only users with restricted access will be able to see the item when creating reports. When an active report is run, restricted columns will be displayed to all users who have access to the report.
カラムへの制限は、グローバルに適用されます。1つのビューに含まれる複数のカラムに対して、異なるユーザーへのアクセス許可を指定することはできません。
レポートを作成するとき、アクセス権をもつユーザーだけがそのカラムを見ることができます。有効なレポートが実行されると、制限がかけられたカラムがそのレポートへのアクセス権を持つすべてのユーザーに表示されます。
bq. 詳細については、[フィールドアクセスと使用方法]を参照してください。
h3. {expand:title=例}
| {*}主な用途{*} | Use if you wish to create a general view available to many users but restrict access to sensitive data to only a few users. || *使うべきでない場合* | Do not use if the view in general and the columns all have the same users that can access them. || *利点* | Can be used to secure specific columns within a view. || *ヒント* | This is a difficult security option to maintain from an administration point of view. Consider alternatives first.Only users with access to the view will be able to have column level access. |{expand}
h2. Access / Value Based Filters
そのビューが多くのユーザーが利用できるべきものであり、デリケートなカラムへのアクセスを許可するユーザーがごく少数で済む場合にお使いください。 |
| {*}使うべきでない場合{*} | そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。 |
| {*}利点{*} | ビューに含まれるカラムに対して個別にセキュリティを設定することができます。 |
| {*}ヒント{*} | 管理の観点から言えばメンテナンスが難しいセキュリティオプションです。できるだけ他の方法を検討してください。ビューへのアクセス権をもつユーザーだけが、カラムレベルのアクセス権を持つことができます。 |
{expand}
h2. アクセスフィルター/値ベースのフィルターの追加
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}
In some時として、一般的な使用のために作成されたビューから、ユーザーの組織内での役職（たとえばコストセンターの管理者など）に関連したデータのみにアクセスさせたい場合があります。そのような場合には、アクセス権、あるいは値に基づくフィルターを作成することができます。
cases
aこれは、たとえばコストセンターとそのユーザーだけがその接続を使えるようソース接続ウイザードをアップデートすることによって実現されます。次にそのビューでソースフィルターと関連する特定のカラムを指定します。つまりビューのどのカラムがコストセンターに関わるカラムであるかを明示するわけです。
view might be created that is designed for general use but you only wish report consumers to access data from the view that is relevant for their position in the organisation - such as cost centre manager. In this case you would create an Access or Value based filter.
This is achieved by updating the source connection wizard to specify the available filters - such as cost centre and your users' relationship to that source. You then specify the specific columns on the view that related to that source filter - e.g. you must indicate which column in the view is the cost centre column.
When writing a report you would specify that the cost centre filter must be used as the access filter. In this case the cost centre that the report reader owns will be passed in as a filter on the query. Only users with access filters defined will be able to see the data in their reports.
レポート作成にあたって、このコストセンターフィルターがアクセス権のフィルターとして働くことを指定します。この場合、レポート閲覧者が所有する権限が、クエリーに関わるフィルターとして渡されます。こうして、定められたアクセス権限をもつユーザーだけが、そのレポートでデータを閲覧することができます。
bq. 詳細については、[ソースアクセスフィルター]を参照してください。
h3. {expand:title=例}
| {*}主な用途{*} | Useそのビューが多くのユーザーが利用できるべきものであり、かつアクセスをデータとユーザーの関係（たとえばコストセンターとその管理者など）に基づいて制限したい場合にお使いください。
ifこのメカニズムは、個人向けのレポートを作成するような場合非常に便利です。値に基づくフィルターを使えば、1つのレポートを多くのユーザー向けに公表することができます。各々のユーザーは同じレポートから自分の権限に見合ったデータだけを閲覧することになります。 you wish| to
create a general view available to many users but restrict access to data based on a users relationship to the data - e.g. cost centre managers.This mechanism is very good for creating Privatised reports. By using value based filters you can create a single report which is distributes to many users. Each user will however, only see their specific / Privatised data. || *使うべきでない場合* | Do not use if the view in general and the columns all have the same users that can access them. || *利点* | Can be used to secure data within a view to only display relevant data. || *ヒント* | This is an easy option to maintain from an administration point of view. This mechanism allows you to provide access to all data within a view to all your users with the security of knowing that they will only see their specific data. || {*}使うべきでない場合{*} | そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。 |
| {*}利点{*} | ビューに含まれるデータのうち、関連のあるデータだけ表示するように制限することができます。 |
| {*}ヒント{*} | これは、管理者から見てメンテナンスのしやすいオプションです。このメカニズムによって、自分がビューの中の特定のデータのみを参照できるということを知っているすべてのユーザーに適切なアクセス権を与えることができます。 |
{expand}
\\
\\
{horizontalrule}
{styleclass: Class=topLink}[ページトップ|#top]
{styleclass}ビューのレポートが少数のユーザーによって作成され、より広いコミュニティに公開されるような場合には、READレベルセキュリティは使わないほうがいいでしょう。代わりにカテゴリーセキュリティを使ってください。
たとえば、ビューがデリケートなデータを含む場合でも、このビューを使って（そのデータを含まない）レポートを作成・配信しなければならないことがあります 。
カテゴリーとビューの両方でアクセスを制限するよりは、単にレポートが所属するカテゴリーでそれを行う方が簡便です。
デリケートなデータがなければ、無用なセキュリティをかけるべきではありません。<!-- /* Style Definitions */ table.MsoNormalTable {mso-style-name:標準の表; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0mm 5.4pt 0mm 5.4pt; mso-para-margin:0mm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";} --> |
Page Comparison
General
Content
Integrations