Page Comparison

{anchor:top}
{toc: class=contents}

h2. Overview概要
{styleclass: Class=topLink}[topページトップ|#top]

{styleclass}
Before管理者はユーザーに対してYellowfinを提供する前に、セキュリティ管理の方針を決定しなければなりません。
deploying Yellowfin to all your users you should determine the security management profiles that you wish to deploy.

The following sections give an overview of how you should approach the security of your Yellowfin application and the access of users to your business critical information.

h2. Security Design Methodology

以下のセクションでは、Yellowfinアプリケーションのセキュリティを確保しつつ、重要なビジネス情報に対するユーザーのアクセス権を設定する方法について概説します。

h2. セキュリティデザインの手順
{styleclass: Class=topLink}[topページトップ|#top]

{styleclass}
The security design methodology described in this guide consists of one planning stage, and two implementation phases:
# Analysis of business needs and planning the security solution
# Designing the security framework
# Implementing your security framework

Each implementation phase is based on an assumption that you have completed an initial planning phase. The planning phase can be done without using administrator, and is the decisive phase for the success or failure of your security. A poorly planned security framework that is not based on a study of your business needs will be difficult to maintain and may enable unauthorized access to sensitive data.
Each of these phases is described as follows:

# *Plan the your security framework before you start using Administrator*
Before starting the first phase, you should spend time understanding your businesses security requirements and how they related to the data that will be exposed to the business through Yellowfin.
You must analyse the security need of the target audience for each data source and view to be implemented. The structures that you use to manage security should be based on a clearly defined user need to access the data contained in those tables and columns and stay consistent with the overall security strategy of your business.
# *Designing the security framework*
You create a security framework by understanding the needs of your users. You have choices to limit users to be report consumers only, limit access to database views, or limit the ability for users to publish reports to the Public repository.
# *Implementing your Security Framework*
Create the user roles, groups, report categories, and provide access to date sources and views to ensure your security requirements are met.  Test these requirements against a sub set of users that have various levels of access.

The table below outlines the major phases in a typical view development cycle:
|| Development phase || Description ||
| Prepare | Identify the target data source and become familiar with its structure.\\
 Know what data is contained within each table of each of the target databases.\\
 Understand the joins.\\
 Identify the cardinality.\\
 Know what is possible. |
| Analyse | Identify the user population and how it is structured; for example is the user group structured by department or by task.\\
 Identify what information the users need.\\
 Identify what standard reports they require.\\
 Familiarise yourself with their business terminology so that you can name items sensibly.\\
 Plan Identify a project strategy. For example, how many views should be created and which ones should have the capacity to be linked and to what level. |
| Implement | Implement your physical view SQL on the target database\\
 Build the Yellowfin view using Administrator. This manual covers this part of the view development cycle, the actual use of the tool.\\
 Test frequently during the build process for validity and reliability of inferred SQL. |
| Test | Form a small group of users, preferably power users who have some knowledge of what information they expect to get from the view. \\
 Pre-Release the view to these users by adding them the access security list for the view.\\
 Ask the users to perform thorough tests simulating live usage of the view(s). |
| Deploy | Change access security of the view so that it is available to the target user base. |
| Evolve | Update and maintain the view as the data sources and user requirements change and grow. |


h2. Analysis Approach
セキュリティデザインは、以下のように1つの計画フェーズと2つの実装フェーズから構成されています：
# ビジネスニーズの分析とセキュリティソリューションの立案
# セキュリティフレームワークの設計
# セキュリティフレームワークの実装

各実装フェーズは、最初の計画フェーズを完了していることが前提となります。計画フェーズは管理プログラムを使わずに実行でき、セキュリティデザインの成否を決定付ける重要なフェーズです。ビジネスニーズを分析せず、無計画にセキュリティフレームワークを構築すると、メンテナンスが困難になるだけでなく、機密データへの不正アクセスを招くおそれがあります。
各フェーズの内容は以下のようなものです：

# *管理プログラムを使い始める前に、セキュリティの骨子を作る*
このフェーズにとりかかる前に、ビジネスにおけるセキュリティの必要性と、それとYellowfinを通して公開されるデータとの関係を理解するために十分な時間を費やさなければなりません。
各々のデータソースとそれに対して作成されるビューに対する利用者のセキュリティニーズを分析してください。セキュリティを管理するのに用いる構造は、それらのテーブルとカラムに含まれるデータに対するユーザーのアクセス権を保証し、かつ全体的なセキュリティ戦略に沿うものである必要があります。
# *セキュリティフレームワークの設計*
ユーザーのニーズに応えて、セキュリティフレームワークを構築します。ここではユーザーの権限をレポートの閲覧だけに限るか、データベースのビューへのアクセス権を与えるか、あるいは共有レポートを作成し公開できる権限まで付与するかを選択します。
# *セキュリティフレームワークの実装*
ユーザーロール、グループ、レポートカテゴリーを構築し、要求されるセキュリティを実現するために、データソースとそのビューにアクセス権を設定します。いろいろなアクセスレベルを持つユーザーのサブセットに対し、要求が満たされているかどうかを検証してください。

以下の表は、一般的なビュー開発の主な段階を示したものです：
|| 開発フェーズ || 説明 ||
| 準備 | ビューを作成するデータソースの内容を精査して、その構造に精通してください。\\
 どのデータベースのどのテーブルにどんなデータが含まれるかについて知らなければなりません。\\
 結合概念について理解してください。\\
 データの多様性を把握してください。\\
 どんなことが可能であるか理解してください。 |
| 分析 | たとえば、部門や仕事の内容によって構築されたユーザーグループなど、ユーザーの数と構成を把握してください。\\
 ユーザーがどんな情報を必要とするかを把握してください。\\
 要求される標準的なレポートはどんなものであるかを把握してください。\\
 わかりやすいフィールド名をつけるために、ユーザーが使うビジネス用語に精通してください。\\
 プロジェクトの戦略についても理解してください。たとえば、いくつのビューが必要で、そのどれ、あるいはどのレベルのものが連結されなければならないかなど。 |
| 実装 | ターゲットデータベースに物理的なビューSQLをインプリメントしてください。\\
 管理プログラムを使ってYellowfinのビューを作成してください。その具体的な方法についてはこのマニュアルで詳しくカバーされています。\\
 SQLの有効性と信頼性をチェックするために、テストを頻繁に行ってください。 |
| テスト\\ | できれば、ビューからどのような情報が得られるかについて若干の知識を有するパワーユーザーの小さなグループを編成してください。\\
 彼らをビューへのアクセスリストに加えてビューをプレリリースします。\\
 彼らに実際の運用を模した綿密なテストを行うよう依頼してください。 |
| 運用 | ビューのアクセスセキュリティを実際のユーザーに合わせて変更します。 |
| 改善 | データソースやユーザーニーズの変化や拡大に応じて、ビューの更新やメンテナンスを行います。 |


h2. 分析アプローチ
{styleclass: Class=topLink}[topページトップ|#top]

{styleclass}
The以下のQ&Aは、セキュリティフレームワークとその戦略を定める参考になるでしょう。
following
questions and responses may assist you to define your security framework and strategy.

| _Do all my users need report writing access?| _すべてのユーザーがレポート作成を行えるアクセス権を必要としていますか？_ | If no then use your *reader role* to only allow users with read access to the system そうでなければ、ユーザーにリードアクセス権だけを与えるために{*}ロール{*}を使いましょう。 |
| _Is the data in my source systems sensitive?ソースシステムにはデリケートな（取り扱いに注意が必要な）データが含まれていますか？_ | If yes then you will need to apply security to your data source.  This will stop unauthorized access to SQL report writers and users that have admin access to the product. そうであれば、データベースに対してセキュリティを適用する必要があります。これは、SQLレポート作成者と管理権のあるユーザーによる無許可のアクセスをブロックします。 |
| _View Security - Is data in my view sensitive.  Can all report writers have access to the data contained in it?_ | If some report writers do not have access to data in the view then view security is required.  The security will stop unauthorized reports being written.ビューセキュリティ：デリケートなデータが存在するとして、すべてのレポート作成者が、それを含むデータにアクセスすることができますか？_ | レポート作成者の一部がビューのデータにアクセスしないのであれば、ビューセキュリティは必要です。セキュリティは、未許可のレポートが作成されるのを防ぎます。 |
| _The majority of the view is not sensitive but only 1 or 2 columns are._ | Define view columns as secure. |
| _If publishing Public reports from the_ *{_}same view{_}* _will some contain sensitive data and other reports not.  For example an HR report containing salaries could be written from the same view as an HR report containing Headcount_ | If some users should be restricted from the salary data you should create two categories for report saving - one for general access which is unsecure and one for secure access.\\
 This assumes that people with report writing access do not have EDIT access to the view - if they do then they could edit a report and add the sensitive data. |
| _Will I be reporting from source systems with completely different subject areas?_ | Best to set up different categories_ビューに含まれるデータのうち、_{_}1{_}{_}つまたは{_}{_}2{_}{_}つのカラムだけデリケートなデータを保持しています。_ | ビューの該当カラムにセキュリティを設定してください。 |
| *{_}同じビュー{_}{*}{_}から共有レポートが公開されるとして、そのいくつかだけがデリケートなデータを含んでいます。たとえば、給料のデータを含む人事レポートは、社員数を含んでいる人事報告と同じビューから作成されます。_ | 一部のユーザーが給料データの閲覧・利用を制限される場合には、2つのカテゴリーを構築してレポートを保存しましょう。1つは一般的なアクセスのためにセキュリティを無効に設定し、もう1つにデリケートなデータを使用できるセキュリティを有効に設定します。\\
 \+このケースでは、レポート作成可能なアクセス権限を持つ人々がビューへのEDITアクセス権を持たないと仮定しています。そうでなければ、彼らはレポートを編集しそれにデリケートなデータを加えることができてしまいます。 |
| _完全に違う分野で同じソースシステムからのレポートが作成されますか？_ | もしそういうことがあるのなら、まったく別個のカテゴリーをセットアップするのが最高の方策です。 |
\\
\\
{horizontalrule}
{styleclass: Class=topLink}[topページトップ|#top]

{styleclass}