Versions Compared

Version Old Version 4 New Version 5
Changes made by

Anonymous

Yellowfin Admin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
top
top

Table of Contents
classcontents

Overview

Security of your Public information is critical. When deploying Yellowfin an analysis of the security needs of your business should be undertaken. Yellowfin has a number of security features that you can use to ensure the security of your Public information. These can be applied is a mix of ways depending upon the level of security that you require. The security features available include:

This section describes the security framework available to you through Yellowfin. It has been set out so that the highest level security features are described first. For instance Access Roles are the highest and easiest to administer form of security whilst column level security is the most granular and by default the most complex to administer over a large user base deployment.

Access Roles & Functions

Yellowfin user management is designed around the concept of user roles. This means that multiple users share a commonly defined role for access to the application. Individual users do not have a unique security profile.

A role is a collection of available security functions. Each user will have a role associated with them. As the Yellowfin report writers you can either:

  1. Change a person’s role – and thus the type of access they have to the application or
  2. Change a role definition by adding or removing functions and thereby updating all users’ access to the system that share that role.

When a user is logged in the system checks that they are still registered in the application and if so what role they should have. Based on the role access the users interface will be dynamically built – only showing them links and functions that their role has access to.

See ロール for more information.

Expand
titleExample

If a user’s role does not have access to the dashboard when they login they will be taken to the report list page. A user with dashboard will be taken in to the dashboard page.

When to use

Use if you wish to limit access to certain functions – such as the ability to write reports

When not to use

Roles cannot be used effectively to limit access to information and data.

Benefits

Easy to maintain for all users.

Tips

Limit the number of roles created at your organization. By increasing the number of roles the level of effort required to manage access increases. Generally only permit a single role per user. Although Yellowfin does support multiple roles it can lead to confusion in a business user.

Report Categories

All reports are managed through a similar security and categorisation infrastructure which is managed through the configuration Content Access function.

The security of your reports is managed at the category and subcategory level, not at the individual item level. The purpose of this is to simplify the creation of reports in the system.

See コンテンツカテゴリー for more information.

Expand
titleExample

Rather than having to specify who is allow to see a specific reports each time you create a new report the security for the report is inherited from the subcategory of the item that is created.

When to use

Use categories to create meaningful business groupings for reports.
If your views are ‘write’ secured then providing access securities to categories allows a user to publish sensitive reports into secure categories for wider but secure read only distribution.

When not to use

Category security is meaningless if users can write reports against a specific view (i.e. it is unsecure) but cannot see a category in which that view logically fits.
For example the Category may be HR reports and the view is a view to the HR database.
If a user can write reports and the view is not secure then whether there is security on the category is largely irrelevant since the user will have access to the base data through report builder.
If all your sensitive views have READ level access defined – applying security to your categories is not required.

Benefits

Category Security is excellent for locking read only users out of specific subject domains.

Tips

Create Subject domains that are intuitive for users to understand.
For example Executive HR – this category can then be made exclusively available to Senior Management for HR reports.
Users publishing reports into categories must be aware of the security of these folders.

Source System Access Management

When setting up a source system in Yellowfin you can define which users have the rights to create views against the source as well as write SQL queries against the source.

The general rule for source system security is that it is used for controlling Yellowfin report writers that wish to create views against the source. It is through this process that a user could write reports against the source system and thereby gain unauthorized access to data.

See データソース for more information.

Expand
titleExample

If the HR system is to be setup as the source system any user with View Definition access will be able to view all tables including payroll data if the source is unsecure. By securing the source to only HR view builders, only those authorized users will be able to define and manage the HR related views.

When to use

Use if you have multiple view administrators – each of whom require access to specific source databases only.
Use if some users have free hand SQL access to write reports and the data in the data source is sensitive.

When not to use

Do not set security on the source in an attempt to limit access to drag and drop report writer users.

Benefits

It is easy to maintain for a select number of users.

Tips

Limit the number of users that have administration access to views. Especially if they wish to edit the same source system.
Multiple administrators can lead to contention issues when managing views.

Note: If there is only 1 Yellowfin report writers of your Yellowfin deployment, and no additional users writing SQL reports then you may consider leaving your source systems unsecure

View Access Management

The main form of security for users creating reports and having access to views which allow them to write any report is through the VIEW security.

When a report is written or edited a user must connect to the view record to determine what fields are available to them. At this stage security check is made to determine if the view that is being accessed is secure, and if so, does the user have the authority to access it.

The security on your view is the most rigorous in terms of managing access to the data that is stored in it. Not only can you control edit access but you can also control which users are permitted to read reports created from the specified view.

See ビューオプション for more information.

Expand
titleExample

The Finance view is created. Only the finance department is permitted to write finance view reports. In this case the view would be defined as secure and the finance users would be added into the access list with edit access.

When to use

Use if you wish to limit users that have access to the report writing function using the specified view.
Use if you wish to be specific in defining which users can read reports created by a specified view but are not permitted to write reports.

When not to use

If reports in the view are to be written by a handful of users and then published to a wider community it is preferable not to use READ level security. Use category access for this.
For example even though the HR view contains sensitive data the HR report writers must write and distribute many reports from this view – most of which do not contain sensitive data.
Simplify security of the view by having secure categories into which the report is saved rather than managing security in both the categories and the view.
If the data contained in the view is not sensitive then do not apply security to it.

Benefits

Easy to maintain for EDIT level security – can become complicated if using READ level security in conjunction with category security.

Tips

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.

Column Access & Restrictions

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.

  1. 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.
  2. 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.
    Note: 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.

See フィールドアクセスと使用方法 for more information.

Expand
titleExample

When to use

Use if you wish to create a general view available to many users but restrict access to sensitive data to only a few users.

When not to use

Do not use if the view in general and the columns all have the same users that can access them.

Benefits

Can be used to secure specific columns within a view.

Tips

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.

Access / Value Based Filters

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.

See ソースアクセスフィルター for more information.

...

titleExample

...

When to use

...

Use if 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.

...

When not to use

...

Do not use if the view in general and the columns all have the same users that can access them.

...

Benefits

...

Can be used to secure data within a view to only display relevant data.

...

Tips

...

概要

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

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

アクセス権と機能

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

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

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

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

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

Expand
title例

ログオンしたユーザーのロールがダッシュボードへのアクセス権を持たない場合、その人にはレポート一覧のページが表示されることになります。ダッシュボードにアクセス権を持つユーザーには、ダッシュボードページが表示されます。

主な用途

アクセスを特定の機能（たとえばレポート作成）に制限したい場合に使用します。

使うべきでない場合

ロールには情報やデータに対するアクセスを制限する効果はありません。

利点

すべてのユーザーに対する設定や更新が簡単です。

ヒント

設定するロールの種類は極力少なくしましょう。ロールが増えるに従って管理が煩雑になります。通常、ユーザー一人につき1つのロールを割り当てるようにしてください。Yellowfinで、一人に複数のロールを割り当てることは、ビジネスユーザーに混乱をもたらしがちです。

レポートカテゴリー

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

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

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

Expand
title例

新しいレポートを作成するたびに誰がそれを見ることができるのか設定しなければならないのは煩雑です。この機能により、新規作成されたレポートのセキュリティは、属するカテゴリーとサブカテゴリーから継承します。

主な用途

レポートの参照を部署などのビジネスグループによって制限する場合に有効です。
編集・更新レベルのセキュリティが設定されているビューで、カテゴリーにアクセス権を与えられているということは、それを閲覧する権限しか持たないカテゴリーに対してレポートを公開する権限を与えることになります。

使うべきでない場合

ユーザーがあるビューからレポートを作成することができるのに（これはすなわちそのビューのセキュリティが無効であることを意味します）、そのビューに論理的に適合するカテゴリーを見つけることができないような場合、カテゴリーを使ったセキュリティに意味はありません。
たとえば、カテゴリーが人事レポートで、ビューが人事データベースのビューだとします。
ビューのセキュリティが無効で、ユーザーがレポートを作成することができる場合、ユーザーはレポートビルダーを通して元のデータにアクセスできるわけですから、カテゴリーに設定されたセキュリティは無意味です。
また、すべてのビューに対して閲覧レベルのアクセス権しか設定しないのであれば、カテゴリーへのセキュリティは必要ありません。

利点

カテゴリーのセキュリティは、閲覧のみのユーザーを特定分野から除外したいときに有効です。

ヒント

カテゴリーはユーザーが直観的に理解できるように作成してください。
たとえば「人事専用」というカテゴリーは、経営幹部が人事のために利用するためだけに使われます。
カテゴリーにレポートを公開するユーザーは、そのカテゴリーのセキュリティについて十分理解していなければなりません。

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

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

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

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

Expand
title例

人事管理システムがソースシステムとしてセットアップされているとして、ソースのセキュリティが無効な場合、ビューを作成できる権限をもつユーザー全員が、従業員名簿を含むすべてのテーブルを閲覧できてしまいます。人事システムにセキュリティを設定することで、許可されたユーザーだけがこのソースに対してビューを作成、管理することができるようになります。

主な用途

複数のビュー管理者がいる場合：管理者ごとにアクセス可能なソースデータベースを指定することができます。
レポート作成のためにソースに対するSQLクエリーの発行を許可しており、かつデリケートなデータが含まれる場合にはお使いください。

使うべきでない場合

レポート作成者にドラッグ＆ドロップによるレポート作成を制限するために使うものではありません。

利点

選ばれた数人のユーザーを管理するのに便利です。

ヒント

ビューの管理権限を持つユーザーの数を制限してください。特に彼らに同じソースシステムを編集させる場合これは重要です。
管理者が複数存在すると、ビューを管理する時に競合の問題が発生することがあります。

注意：稼働中のYellowfinでレポート作成者が1人しかおらず、ソースにSQLクエリーを発行できるユーザーもいない場合には、ソースシステムのセキュリティを無効に設定しておいてもかまいません。

ビューのアクセス管理

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

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

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

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

Expand
title例

たとえば財務に関するビューが作成され、財務部だけが、そのビューを使ったレポートの作成を許されているとします。この場合、ビューをセキュアに設定し、財務部に属するユーザーを編集のアクセス権を持つアクセスリストに加えます。

主な用途

特定のビューを使ってレポートを作成できるユーザーを制限したい場合に使うべきです。
特定のビューによって作成されたレポートについて、閲覧することはできるものの作成する権限を持たないユーザーを設定したい場合にも使用します。

使うべきでない場合

ビューのレポートが少数のユーザーによって作成され、より広いコミュニティに公開されるような場合には、閲覧レベルのセキュリティは使わないほうがいいでしょう。代わりにカテゴリーのセキュリティを使ってください。
たとえば、ビューがデリケートなデータを含む場合でも、このビューを使って（そのデータを含まない）レポートを作成して配信しなければならないことがあります。
カテゴリーとビューの両方でアクセスを制限するよりは、単にレポートが所属するカテゴリーでそれを制限する方が簡単です。
デリケートなデータがないのであれ、無用なセキュリティをかけるべきではありません。

利点

編集・更新レベルセキュリティを管理するのが簡単です。カテゴリーセキュリティと一緒に閲覧レベルのセキュリティを使うことは混乱の原因になりがちです。

ヒント

そのビューに対して誰がレポートを作成しているか、またそのレポートが誰に向けて作成されているのかを把握する必要がある場合には、これを使うのが良いでしょう。また、レポートが広く公開されるものならば、参照の制限をかけるべきではありません。

カラムアクセスと制限

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

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

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

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

Expand
title例

主な用途

そのビューが多くのユーザーが利用できるべきものであり、デリケートなカラムへのアクセスを許可するユーザーがごく少数で済む場合にお使いください。

使うべきでない場合

そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。

利点

ビューに含まれるカラムに対して個別にセキュリティを設定することができます。

ヒント

管理の観点から言えばメンテナンスが難しいセキュリティオプションです。できるだけ他の方法を検討してください。
ビューへのアクセス権をもつユーザーだけが、カラムレベルのアクセス権を持つことができます。

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

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

たとえばコストセンターとそのユーザーだけがそデータソースを使えるようにデータソース接続の設定を変更してください。次にそのビューでソースフィルターに関連する特定のカラムを指定します。つまりビューのどのカラムがコストセンターに関わるカラムであるかを明示するわけです。

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

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

Expand
title例

主な用途

そのビューが多くのユーザーが利用できるべきものであり、かつアクセス権をデータとユーザーの関係（たとえばコストセンターとその管理者など）に基づいて制限したい場合にお使いください。
このメカニズムは、個人向けのレポートを作成するような場合非常に便利です。値に基づくフィルターを使えば、1つのレポートを多くのユーザー向けに公開することができます。各々のユーザーは同じレポートから自分の権限に見合ったデータだけを閲覧することができます。

使うべきでない場合

そのビューが一般的なものであり、ユーザーがそれに含まれるカラムすべてに同じようにアクセスできるような場合には使うべきではありません。

利点

ビューに含まれるデータのうち、関連のあるデータだけ表示するように制限することができます。

ヒント

これは、管理者から見てメンテナンスのしやすいオプションです。
このメカニズムによって、自分がビューの中の特定のデータのみを参照できるということを知っているすべてのユーザーに適切なアクセス権を与えることができます。