Управление доступом к DB2 на основе меток: Практическое руководство, часть 1: Представление об основах LBAC в DB2

• Упражнение 1: Защита строк
• Упражнение 2: Защита столбцов
• Упражнение 3: Защита строк и столбцов

Упражнение 1: Защита строк

В этом упражнении будет показано, как использовать защиту на уровне строк для управления доступом к строкам в таблице.

В отделе продаж Global Life Financial существует соревнование среди региональных менеджеров по продажам. Победителем считается менеджер, в регионе которого план продаж превышается по самой большой марже. Руководители компании контролируют соревновательный процесс и имеют доступ ко всем отчетам о продажах, а для поддержания духа соперничества региональные менеджеры могут просматривтаь только свои данные по продажам.

Рис. 1. Старшие руководители могут просматривать все записи, региональные менеджеры - только строки для своего региона

В соревновании участвует четыре региона. Два из участвующих регионов "Центр-Север" и "Центр-Юг" фактически являются субрегионами региона "Центр" и получают инструкции по продажам от главного менеджера этого региона. (Примечание: регион "Центр" не включен в соревнование, его главный менеджер является заинтересованным наблюдателем). Два старших руководителя, управляющие отделом продаж, действуют как администраторы соревнований. Участники соревнований и их роли представлены в следующей таблице.

Таблица 1. Участники соревнований и администраторы

Все данные о соревновании хранятся в таблице SALES. Эту таблицу необходимо создать, и она должна быть аналогична существующей таблице PERFORMANCE.

Таблица 2. Описание таблицы PERFORMANCE

В следующем разделе проанализируем требования к безопасности.

Анализ ограничений данных

В этом упражнении необходимо определить способ управления доступом к таблице SALES. Необходимо использовать следующие ограничения:

1. Региональным менеджерам по продажам предоставлен доступ на с правом READ/WRITE (ЧТЕНИЯ/ЗАПИСИ) только к записям для своих регионов.
2. Главный менеджер региона "Центр" может просматривать записи регионов "Центр-север" и "Центра-юг".
3. Руководители имеют доступ на чтение всех записей.

На основе этого сценария подведем итог к требованиям по безопасности:

Таблица 3. Требования по безопасности

На основе анализа принято решение обеспечить защиту данных о продажах на уровне строк. Для защиты таблицы на уровне строк LBAC позволяет присвоить каждой строке метку защиты. Затем можно предоставить пользователям метки защиты, открывающие им доступ к соответствующим строкам таблицы. В таком случае следует создать таблицу SALES на основе существующей таблицы PERFORMANCE (Таблица 2), но с дополнительным столбцом для метки защиты строк.

Таблица 4. Столбец меток защиты, необходимый для управления доступом

Далее на основе анализа спроектируем решение LBAC по обеспечению безопасности.

Проектирование решения по обеспечению безопасности

В данном упражнении спроектируем метки защиты, управляющие доступом к данным в таблице SALES. При проектировании меток защиты необходимо рассмотреть следующие вопросы:

1. Метки защиты строк.
2. Пользовательские метки защиты, предоставляемые пользователям для соответствующего доступа.
3. Компоненты меток защиты для создания меток защиты.

Метки защиты строк

На основе анализа определено, что для каждого региона требуется метка защиты для управления доступом к данным этого региона. Поэтому требуется четыре метки защиты, по одной для каждого региона продаж. Компоненты меток защиты для создания этих меток защиты можно разработать, используя в качестве элементов регионы продаж. Все регионы имеют одинаковое значение, поэтому для этого компонента метки защиты можно использовать оператор SET.

Пользовательские метки защиты для региональных менеджеров

Соответствующие метки защиты, назначаемые строкам, предоставляются региональным менеджерам для обеспечения доступа к данным своего региона. Доступ менеджеров к таким данным имеет статус "READ/WRITE".

Метка защиты для главного менеджера

Главный менеджер региона "Центр" может просматривать данные регионов "Центр-север" и "Центр-юг", поэтому его метка защиты должна иметь больший приоритет в сравнении с метками защиты строк для этих субрегионов. Так как в данном случае речь идет об иерархии, можно рассмотреть использование ARRAY или TREE для другого компонента меток защиты.

Главный менеджер не имеет права на запись в таблицу SALES, поэтому необходимо использовать некоторые ограничения на уровне таблицы при отзыве у этого пользователя привилегий INSERT, UPDATE и DELETE. Такие типы ограничений не являются частью компонента метки защиты или самой метки защиты, но их необходимо использовать при GRANT (предоставлении) пользователям меток защиты.

Пользовательские метки защиты для руководителей

Руководители могут просматривать все данные о продажах. Один из способов заключается в предоставлении руководителям всех меток защиты, но это вряд ли можно назвать наиболее эффективным методов. Другой способ - использование иерархической структуры, в которой метки защиты, предоставляемые руководителям, имеют больший приоритет в сравнении с метками защиты, используемыми для защиты строк. Такая иерархия должна соответствовать организационной структуре компании, поэтому она слишком сложна для ARRAY, и необходимо рассмотреть использование элемента TREE.

Руководители, как и главный менеджер, не имеют права на ЗАПИСЬ(WRITE) в таблицу SALES, поэтому необходимо использовать ограничения на запись.

Компоненты меток защиты

Так как доступ к данным основан на делении по географическим регионам компании Global Life Financial, компонент метки защиты можно создать с помощью структуры TREE с регионами в качестве элементов.

Рис. 2. Компонент метки защиты типа TREE

Используя для создания компонента меток защиты узлы в древовидной структуре, можно создать четыре метки защиты строк: по одной для каждого региона. Например, метку защиты для добавления к записи о продажах в регионе "Западное побережье" можно разработать с использованием элемента 'WEST_COAST' из компонента меток защиты.

Для предоставления руководителям доступа ко всей таблице SALES их метки защиты должны иметь более высокий уровень привилегий в сравнении с менеджерами по продажам. Метка защиты, созданная с использованием элемента 'SALES_ORGANIZATION', означает, что пользователь, которому предоставлена метка защиты, имеет доступ ко всем записям таблицы с метками защиты, созданными с помощью элементов, находящихся ниже в древовидной структуре.

В следующем разделе показано, как реализовать спроектированное решение с помощью команд SQL.

Реализация решения по обеспечению безопасности

Обзор этапов:

1. Определение правил и меток защиты:
   • Определение компонентов меток защиты;
   • Определение правила защиты;
   • Определение меток защиты.
2. Создание защищенной таблицы SALES с помощью добавления столбца для метки защиты и назначения таблице правила защиты;
3. Предоставление пользователям соответствующих меток защиты.

Этап 1: Определение правил и меток защиты

Требования к привилегиям и полномочиям

Для выполнения команд по созданию правил и меток защиты требуются полномочия SECADM.

Этап 1a: Определение компонентов меток защиты

На основе анализа решено, что можно использовать компонент меток защиты типа TREE с регионами продаж в качестве элементов. Компонент меток защиты SLC_REGION типа TREE с элементами показан на рисунке 2, его можно создать с помощью следующей команды:

					
        CREATE SECURITY LABEL COMPONENT SLC_REGION
        TREE {'SALES_ORGANIZATION' ROOT,
              'CENTRAL' UNDER 'SALES_ORGANIZATION',
              'CENTRAL_NORTH' UNDER 'CENTRAL',
              'CENTRAL_SOUTH' UNDER 'CENTRAL',
              'WEST_COAST' UNDER 'SALES_ORGANIZATION',
              'EAST_COAST' UNDER 'SALES_ORGANIZATION'
        }
        

Этап 1b: Определение правила защиты

После создания компонента меток защиты необходимо создать правило защиты. Правило защиты SALES_REGION_POLICY, использующее компонент SLC_REGION, можно создать с помощью следующей команды:

        CREATE SECURITY POLICY SALES_REGION_POLICY
             COMPONENTS SLC_REGION
             WITH DB2LBACRULES
             RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
        

Этап 1c: Определение меток защиты

На основе анализа решено, что метка защиты требуется для каждого региона продаж (всего четыре), для главного менеджера и для руководителей. Каждая метка защиты основана на правиле защиты SALES_REGION_POLICY, созданном на этапе 1b. Необходимые метки защиты создаются с помощью следующих команд:

        CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL_SOUTH
             COMPONENT SLC_REGION 'CENTRAL_SOUTH'
        
        CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL_NORTH
             COMPONENT SLC_REGION 'CENTRAL_NORTH'
             
        CREATE SECURITY LABEL SALES_REGION_POLICY.EAST_COAST
             COMPONENT SLC_REGION 'EAST_COAST'

        CREATE SECURITY LABEL SALES_REGION_POLICY.WEST_COAST
             COMPONENT SLC_REGION 'WEST_COAST'

        CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL
             COMPONENT SLC_REGION 'CENTRAL'

        CREATE SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
             COMPONENT SLC_REGION 'SALES_ORGANIZATION'
        

Этап 2: Создание защищенной таблицы SALES

Требования к привилегиям и полномочиям

Возможность создания таблиц:

Для обеспечения безопасности таблицы SALES на уровне строк требуется столбец типа DB2SECUIRTYLABEL для меток защиты и связи таблицы с правилом защиты SALES_REGION_POLICY.

        CREATE TABLE SALES (SALES_DATE DATE,
             SALES_PERSON VARCHAR (15),
             REGION VARCHAR (15),
             SALES INTEGER,
             MARGIN INTEGER,
             REGION_TAG DB2SECURITYLABEL)
             SECURITY POLICY SALES_REGION_POLICY
        

После успешного выполнения команды таблица SALES защищена.

Таблица 5. Описание защищенной таблицы SALES

После заполнения данными из таблицы PERFORMANCE таблица SALES выглядит следующим образом.

Таблица 6. Каждой строке присвоена метка защиты, управляющая доступом на основе региона

Этап 3: Предоставление пользователям меток защиты

Требования к привилегиям и полномочиям

Для выполнения команд по предоставлению меток пользователям требуются полномочия SECADM.

После защиты таблицы SALES пользователи без меток защиты не имеют доступа к этой таблице. Чтобы предоставить региональным менеджерам доступ к региональным данным в таблице SALES, предоставьте каждому менеджеру метку защиты, соответствующую региону продаж с правом на READ/WRITE (ЧТЕНИЕ/ЗАПИСЬ). Например, Nick является менеджером по продажам в регионе "Западное побережье", ему нужно предоставить метку защиты SALES_REGION_POLICY.WEST_COAST. Главному менеджеру Sean предоставьте метку защиты SALES_REGION_POLICY.CENTRAL с правом чтения. Руководителям Paul и Bob предоставьте метку защиты SALES_REGION_POLICY.SALES_ORG_READ с правом чтения всех записей в таблице.

        GRANT SECURITY LABEL SALES_REGION_POLICY.EAST_COAST
            TO USER Sam FOR ALL ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.WEST_COAST
            TO USER Nick FOR ALL ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL_NORTH
            TO USER Becky FOR ALL ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL_SOUTH
            TO USER Marc FOR ALL ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL
            TO USER Sean FOR READ ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
            TO USER Paul FOR READ ACCESS
            
        GRANT SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
            TO USER Bob FOR READ ACCESS
        

В следующем разделе показано, насколько хорошо действует решение LBAC по обеспечению безопасности.

Решение в действии

В данном разделе описаны некоторые сценарии, возможные после защиты таблицы SALES.

Пример 1

Sam, менеджер по продажам региона "Восточное побережье", пытается добавить данные в таблицу SALES:

        INSERT into INSURANCE.SALES VALUES (
            '2005-02-28',
            'LUCCHESSI',
            'East-Coast',
            344,
            40,
            SECLABEL_BY_NAME('SALES_REGION_POLICY', 'SL_EAST_COAST'));
        

Команда выполняется успешно. Результирующая строка содержит:

('2005-02-28','LUCCHESSI','East-Coast',344,40,<SALES_REGION_POLICY.EAST_COAST>)

Пример 2

Sam пытается вставить данные о продажах другого региона:

        INSERT into INSURANCE.SALES VALUES (
             '2005-02-28',
             'Brian',
             'Central-South',
             344,
             28,
             SECLABEL_BY_NAME ('SALES_REGION_POLICY', 'SL_CENTRAL_SOUTH'))
        

Команда вызывает ошибку, потому что Sam не предоставлена метка защиты SALES_REGION_POLICY.CENTRAL_SOUTH.

Примечание: Если в команде CREATE SECURITY POLICY не задана опция RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL, команда выполняется успешно. Но метка защиты Sam с правом на запись будет записываться в последний столбец вместо SL_CENTRAL_SOUTH.

Пример 3

Sam пытается вставить данные о продажах, используя предоставленную метку защиты:

        INSERT into INSURANCE.SALES (
             SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
             VALUES (
             '2005-02-12',
             'Peter',
             'East-Coast',
             450,
             40)
        

Команда выполняется успешно. Возвращаются две строки, добавленные в примерах 1 и 2:

('2005-02-28','LUCCHESSI','East-Coast',344,40,<SALES_REGION_POLICY.EAST_COAST>)
('2005-02-12','Peter','East-Coast',450,40,<SALES_REGION_POLICY.SL_EAST_COAST>)

Пример 4

Marc, менеджер по продажам региона "Центр-юг", пытается добавить в таблицу данные о продажах:

        INSERT into INSURANCE.SALES (
             SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
             VALUES (
             '2005-02-25',
             'Brian',
             'Central-South',
             390,
             43,
             SECLABEL_BY_NAME('SALES_REGION_POLICY', 'SL_CENTRAL_SOUTH'));
        

Команда выполняется успешно. Результирующая строка содержит:

('2005-02-25','Brian','Central-South',390,43,<SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)

Затем Marc пытается просмотреть таблицу с помощью команды:

        SELECT sales_date, sales_person, region, sales, margin, 
             varchar(SECLABEL_TO_CHAR("SALES_REGION_POLICY',REGION_TAG), 30) 
             from INSURANCE.SALES
        

Возвращаются строки с метками защиты SALES_REGION_POLICY.CENTRAL_SOUTH:

('2005-02-25','Brian','Central-South',390,43,<SALES_REGION_POLICY.CENTRAL_SOUTH>)

Пример 5

Sam пытается просмотреть данные о продажах по другому региону с помощью команды:

        SELECT sales_date, sales_person, region, sales, margin, 
             varchar(SECLABEL_TO_CHAR('SALES_REGION_POLICY',REGION_TAG), 30)
             from INSURANCE.SALES where REGION='Central-South'
        

Строки не возвращаются. Строка со значением "Центр-юг" в столбце региона защищена меткой защиты SALES_REGION_POLICY.SL_CENTRAL_SOUTH. Метка защиты с правом на чтение, имеющаяся у Sam, не предоставляет прав на чтение таких строк.

Пример 6

Sam пытается просмотреть данные из таблицы INSURANCE.SALES с помощью следующей команды:

           SELECT sales_date, sales_person, region, sales, margin, 
                varchar(SECLABEL_TO_CHAR('SALES_REGION_POLICY',REGION_TAG), 30)
                from INSURANCE.SALES;
        

Возвращается строка с меткой SALES_REGION_POLICY.SL_EAST_COAST в качестве значения REGION_TAG:

('2005-02-28','LUCCHESSI','East-Coast',344,40,<SALES_REGION_POLICY.SL_EAST_COAST>)
('2005-02-12','Peter','East-Coast',450,40,<SALES_REGION_POLICY.SL_EAST_COAST>)

Пример 7

Becky, менеджер по продажам региона "Центр-север", пытается добавить данные о продажах для другого региона, используя предоставленную метку защиты:

        INSERT into INSURANCE.SALES (
             SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
             VALUES ('2005-01-28',
             'Owen',
             'Central-North',
             300,
             36,
             SECLABEL_BY_NAME('SALES_REGION_POLICY', 'SL_CENTRAL_NORTH'));
        

Команда выполняется успешно. Результирующая строка содержит:

('2005-01-28','Owen','Central-North',300,36,<SALES_REGION_POLICY.SL_CENTRAL_NORTH>)

Затем Becky пытается просмотреть таблицу с помощью команды:

        SELECT sales_date, sales_person, region, sales, margin, 
             varchar(SECLABEL_TO_CHAR('SALES_REGION_POLICY',REGION_TAG), 30)
             from INSURANCE.SALES
        

Возвращаются строки с метками защиты SALES_REGION_POLICY.CENTRAL_NORTH:

('2005-01-28','Owen','Central-North',300,36,SL_CENTRAL_NORTH)

Пример 8

Sean, главный менеджер региона "Центр", пытается просмотреть данные о продажах в регионах:

        SELECT sales_date, sales_person, region, sales, margin, 
             varchar(SECLABEL_TO_CHAR('SALES_REGION_POLICY',REGION_TAG), 30)
             from INSURANCE.SALES
        

Команда возвращает строки с метками защиты SALES_REGION_POLICY.SL_CENTRAL_SOUTH или SALES_REGION_POLICY.SL_CENTRAL_NORTH:

('2005-02-25','Brian','Central-South',390,43,<SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)
('2005-01-28','Owen','Central-North',300,36,<SALES_REGION_POLICY.SL_CENTRAL_NORTH>)

Пример 9

Paul, старший руководитель, пытается просмотреть данные о продажах с помощью команды:

        SELECT sales_date, sales_person, region, sales, margin, 
             varchar(SECLABEL_TO_CHAR('SALES_REGION_POLICY',REGION_TAG), 30) 
             from INSURANCE.SALES
        

Команда выполняется успешно и возвращает все строки таблицы INSURANCE.SALES:

('2005-02-28','LUCCHESSI','East-Coast',344,40,<SALES_REGION_POLICY.EAST_COAST>)
('2005-02-12','Peter','East-Coast',450,40,<SALES_REGION_POLICY.SL_EAST_COAST>)
('2005-02-25','Brian','Central-South',390,43,<SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)
('2005-01-28','Owen','Central-North',300,36,<SALES_REGION_POLICY.SL_CENTRAL_NORTH>)

Упражнение 2: Защита столбцов

В этом упражнении будет показано, как использовать защиту на уровне столбцов для управления доступом к столбцам в таблице.

Отдел кадров компании Global Life Financial хотел бы предоставить доступ сотрудникам, менеджерам и служащим отдела кадров доступ к данным в таблице EMPLOYEE. В этой таблице содержится информация с различным уровнем важности, поэтому необходимо использовать некоторые ограничения доступа:

• Имя, пол, отдел и номер телефона считаются несекретной информацией и доступны для всех сотрудников;
• Табельный номер, дата приема, должность и образование считаются конфиденциальными, доступ к этим данным должны иметь только менеджеры и сотрудники отдела кадров;
• Дата рождения, зарпалата, бонусы и комиссионные считаются сугубо конфиденциальной информацией, доступ к которой имеют только сотрудники отдела кадров.

Рис. 3. Уровни доступа к таблице EMPLOYEE

Некоторые пользователи, имеющие доступ к таблице, представлены в следующей таблице.

Таблица 7. Персонал с доступом к таблице EMPLOYEE.

Существующей таблице EMPLOYEE присвоены метки защиты, указывающие уровень важности столбцов.

Таблица 8. Классификация столбцов в таблице EMPLOYEE.

В следующем разделе проанализируем требования к безопасности.

Анализ ограничений данных

В этом упражнении необходимо определить способ управления доступом к столбцам таблицы EMPLOYEE. Необходимо использовать следующие ограничения:

1. Любые пользователи с доступом к таблице EMPLOYEE могут просматривать столбцы с несекретной информацией.
2. Менеджеры также могут просматривать все столбцы с конфиденциальной информацией.
3. Персонала отдела кадров имеет доступ с правом READ/WRITE ко все столбцам таблицы.

На основе этого сценария подведем итог к требованиям по безопасности:

Таблица 9. Требования по безопасности

Далее на основе анализа спроектируем решение LBAC по обеспечению безопасности.

Проектирование решения по обеспечению безопасности

В данном упражнении спроектируем метки защиты, управляющие доступом к столбцам в таблице EMPLOYEE. При проектировании меток защиты необходимо рассмотреть следующие вопросы:

1. Метки защиты столбцов с различной степенью важности.
2. Пользовательские метки защиты, предоставляемые пользователям для соответствующего доступа.
3. Компоненты меток защиты для создания меток защиты.

Метки защиты столбцов

На основе анализа определено, что каждому столбцу необходимо присвоить метку защиты на основе важности информации. Поэтому требуется три метки защиты, по одной для каждого уровня важности: HIGHLY CONFIDENTIAL, CONFIDENTIAL и UNCLASSIFIED. Это простая иерархия, поэтому подумайте об использовании для компонента меток защиты ARRAY.

Пользовательские метки защиты для сотрудников компании

Постоянные сотрудники имеют доступ только к несекретной информации. Если несекретные столбцы защищены меткой защиты UNCLASSIFIED, эту метку необходимо предоставить постоянным сотрудникам.

Постоянным сотрудникам запрещена запись в таблицу EMPLOYEE, поэтому на уровне таблицы необходимо использовать некоторые ограничения при отзыве у этих пользователей привилегий INSERT, UPDATE и DELETE при ПРЕДОСТАВЛЕНИИ (GRANT) им меток защиты.

Пользовательские метки защиты для менеджеров

Менеджеры имеют доступ к несекретной и конфиденциальной информации. Если несекретные столбцы защищены меткой защиты CONFIDENTIAL, эту метку необходимо предоставить менеджерам. Для меток защиты можно использовать ARRAY. Если порядок элементов в массиве (CONFIDENTIAL, UNCLASSIFIED), то менеджеры с меткой защиты CONFIDENTIAL имеют доступ ко все информации на уровне CONFIDENTIAL и нижележащим уровням (в данном случае UNCLASSIFIED).

Менеджерам также запрещена запись в таблицу EMPLOYEE, поэтому на уровне таблицы необходимо использовать некоторые ограничения при отзыве у этих пользователей привилений INSERT, UPDATE и DELETE.

Пользовательские метки защиты для сотрудников отдела кадров

Сотрудники отдела кадров имеют высший уровень доступа к таблице EMPLOYEE и имеют доступ ко всей информации. Если сугубо конфиденциальные столбцы защищены меткой защиты HIGHLY CONFIDENTIAL, такие метки необходимо предоставить сотрудникам отдела кадров. В данном случае для меток защиты можно использовать МАССИВ (ARRAY). Если в массиве (HIGHLY CONFIDENTIAL, CONFIDENTIAL, UNCLASSIFIED) имеет значение порядок, то сотрудники отдела кадров с предоставленной меткой защиты HIGHLY CONFIDENTIAL имеют доступ ко всей информации на уровне HIGHLY CONFIDENTIAL и на нижних уровнях (в данном случае CONFIDENTIAL и UNCLASSIFIED).

Доступ к данным в таблице EMPLOYEE table должен иметь право READ/WRITE (ЧТЕНИЯ/ЗАПИСИ).

Компоненты меток защиты

Доступ к данным основан на линейной иерархии, поэтому компонент меток защиты можно создать с помощью МАССИВА (ARRAY) с порядком HIGHLY CONFIDENTIAL, CONFIDENTIAL, UNCLASSIFIED.

В следующем разделе показано, как реализовать спроектированное решение с помощью команд SQL.

Реализация решения по обеспечению безопасности

Обзор этапов:

1. Определение правил и меток защиты:
   • Определение компонентов меток защиты;
   • Определение правила защиты;
   • Определение меток защиты.
2. Изменение таблицы EMPLOYEE с помощью присвоения всем столбцам меток защиты и назначения таблице правила защиты;
3. Предоставление пользователям соответствующих меток защиты.

Этап 1: Определение правил и меток защиты

Требования к привилегиям и полномочиям

Для выполнения команд по созданию правил и меток защиты требуются полномочия SECADM.

Этап 1a: Определение компонентов меток защиты

На основе анализа решено, что компонент меток защиты типа "массив" можно использовать для упорядоченного набора элементов: HIGHLY CONFIDENTIAL, CONFIDENTIAL и UNCLASSIFIED. Компоненты меток защиты можно создать с помощью следующих команд:

					
        CREATE SECURITY LABEL COMPONENT SLC_LEVEL
        ARRAY ['HIGHLY CONFIDENTIAL', 'CONFIDENTIAL', 'UNCLASSIFIED']
        

Этап 1b: Определение правила защиты

После создания компонента меток защиты необходимо создать правило защиты. Правило защиты ACCESS_EMPLOYEE_POLICY, использующее компонент SLC_LEVEL, можно создать с помощью следующей команды:

        CREATE SECURITY POLICY ACCESS_EMPLOYEE_POLICY
             COMPONENTS SLC_LEVEL
             WITH DB2LBACRULES
             RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
        

Этап 1c: Определение меток защиты

На основе анализа решено, что метка защиты требуется для каждого типа классификации (всего три типа). Каждая метка защиты основана на правиле защиты ACCESS_EMPLOYEE_POLICY, созданном на этапе 1b. Необходимые метки защиты создаются с помощью следующих команд:

        CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
             COMPONENT SLC_LEVEL 'HIGHLY CONFIDENTIAL'
             
        CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
             COMPONENT SLC_LEVEL 'CONFIDENTIAL'
             
        CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
             COMPONENT SLC_LEVEL 'UNCLASSIFIED'
        

Этап 2: Изменение таблицы EMPLOYEE

Требования к привилегиям и полномочиям

ИЗМЕНИТЕ (ALTER) привилегии таблицы EMPLOYEE:

Для защиты таблицы EMPLOYEE на уровне столбцов необходимо изменить столбцы, назначив соответствующие метки защиты, и связать таблицу с правилом защиты ACCESS_EMPLOYEE_POLICY.

        ALTER TABLE EMPLOYEE
            ALTER EMPNO SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
            ALTER FIRSTNME SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER MIDINIT SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER LASTNAME SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER WORKDEPT SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER PHONENO SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER GENDER  SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            ALTER HIREDATE SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
            ALTER JOB SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
            ALTER EDLEVEL SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
            ALTER BIRTHDATE SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
            ALTER SALARY SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
            ALTER BONUS SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
            ALTER COMM SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
            ADD SECURITY POLICY ACCESS_EMPLOYEE_POLICY
        

После успешного выполнения команд таблица EMPLOYEE защищена.

Этап 3: Предоставление пользователям меток защиты

Требования к привилегиям и полномочиям

Для выполения команд по предоставлению пользователям меток защиты требуются полномочия SECADM.

После защиты таблицы EMPLOYEE пользователи без меток защиты не имеют доступа к этой таблице. Чтобы разрешить сотрудникам доступ к защищенной таблице EMPLOYEE, необходимо предоставить им следующие метки:

        GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
            TO USER Jen
            FOR ALL ACCESS
        
        GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
            TO USER Noel
            FOR READ ACCESS
        
        GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
            TO USER Sunny
            FOR READ ACCESS        
        

В следующем разделе показано, насколько хорошо действует решение LBAC по обеспечению безопасности.

Решение в действии

В данном разделе описаны некоторые сценарии, возможные после защиты таблицы SALES.

Пример 1

Jen, сотрудник отдела кадров, пытается просмотреть таблицу EMPLOYEE с помощью следующей команды:

        SELECT * from EMPLOYEE;
        

Команда выполняется успешно.

Пример 2

Менеджер Noel пытается просмотреть таблицу EMPLOYEE с помощью команды:

        SELECT * from HR.EMPLOYEE;
        

Команда вызвает ошибку, так как нарушает ограничения прав на чтение сугубо конфиденциальных столбцов.

Затем Noel пытается просмотреть только столбцы с несекретной и конфиденциальной информацией:

        SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, 
             PHONENO, HIREDATE, JOB, EDLEVEL 
             from HR.EMPLOYEE;
        

Команда выполняется успешно.

Пример 3

Постоянный сотрудник Sunny пытается просмотреть таблицу EMPLOYEE с помощью команды:

           SELECT FIRSTNME, LASTNAME, PHONENO from HR.EMPLOYEE;
        

Команда выполняется успешно, так как Sunny имеет метку защиты ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED и пытается просмотреть только несекретную информацию.

Затем Sunny пытается просмотреть столбцы с конфиденциальными данными:

        SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, 
             WORKDEPT, PHONENO, HIREDATE, JOB, EDLEVEL
             from HR.EMPLOYEE;

Команда вызывает ошибку, потому что нарушает ограничения доступа на чтения.

Упражнение 3: Защита строк и столбцов

В этом упражнении будет показано, как использовать комбинацию защиты на уровне строк и столбцов для защиты важных данных в таблице.

В компании Global Life Financial требуется, чтобы все заявители на страхование жизни передали в компанию историю болезни для анализа приемлемости их заявления. История болезни заявителя является сугубо конфиденциальной информацией и должна обрабатываться только в отделе анализа медицинских карт. После анализа истории болезни отдел предоставляет свою оценку в форме индекса риска. Затем менеджеры отдела могут запрашивать индекс страхового риска при рассмотрении утверждения заявления о страховании. Для сохранения конфиденциальности менеджеры отдела не имеют доступа к информации, связанной с историей болезни клиента.

Истории болезней и индекс риска хранятся в таблице MEDICAL_RECORD.

Рис. 4. Уровни доступа к таблице MEDICAL_RERORT.

Далее в таблице перечислены сотрудники, имеющие доступ к таблице MEDICAL_RERORT.

Таблица 10. Персонал, имеющий доступ к таблице MEDICAL_RECORD.

В таблице MEDICAL_RERORT к столбцам с конфиденциальной информацией имеют доступ только аналитики истории болезней. Доступ менеджеров ограничен записями клиентов, относящимся к отделу менеджера.

Таблица 11. Определение таблицы MEDICAL_RECORD.

В следующем разделе проанализируем требования к безопасности.

Анализ ограничений данных

В этом упражнении необходимо определить, как управлять доступом к столбцам с конфиденциальной информацией и как ограничить доступ к записям по группам. Необходимо использовать следующие ограничения:

• Столбцы:
  • Аналитики истории болезни имеют доступ READ/WRITE к столбцам с конфиденциальной информацией;
  • Менеджеры имеют доступ READ к столбцам с несекретной информацией.
• Строки:
  • Аналитики истории болезни могут просматривать и обновлять все данные;
  • Менеджеры могут просматривать, но не обновлять записи о клиентах своего отдела.

На основе этого сценария подведем итог к требованиям по безопасности:

Таблица 12. Требования по безопасности

Для ограничения доступа к столбцам с конфиденциальной информацией, столбцы можно защитить с помощью меток защиты. Для ограничения доступа менеджеров только записями своего отдела каждой строке можно присвоить метку защиты, указывающую отдел. Ограничение на запись для менеджеров можно выполнить с помощью отзыва прав на запись в таблицу. Ниже в таблице 13 показано, как метка защиты добавляется к столбцу MEDICAL_HISTORY и служит для управления доступом к категории должностей.

Таблица 13. Добавляется метка защиты строки для управления доступом по отделу.

Далее на основе анализа спроектируем решение LBAC по обеспечению безопасности.

Проектирование решение по обеспечению безопасности

В данном упражнении спроектируем метки защиты, управляющие доступом к данным в таблице MEDICAL_RECORD. При проектировании решения по обеспечению безопасности необходимо учесть следующее:

1. Метки защиты строк и столбцов;
2. Пользовательские метки защиты, предоставляемые пользователям для соответствующего доступа;
3. Компоненты меток защиты для создания меток защиты.

Метки защиты столбцов

Для защиты столбцов с конфиденциальной информацией требуется использовать метки защиты столбцов. Компонент метки защиты для создания такой метки защиты может быть просто элементом с именем CONFIDENTIAL. Использование SET выглядит целесообразным, так как имеется только один элемент.

Метки защиты строк

На основе анализа определено, что для каждого отдела требуется метка защиты для управления доступом к данным. Поэтому требуется четыре метки защиты, по одной для каждого отдела. Все отделы имеют одинаковое значение, поэтому для этого компонента метки защиты можно использовать оператор SET.

Пользовательская метка защиты для аналитиков истории болезни

Аналитик истории болезней имеет доступ READ/WRITE ко всем записям для всех отделов, включая столбцы с конфиденциальной информацией. Поэтому данная метка защиты должна включать элементы метки защиты столбцов и метки защиты строк. Так как аналитик истории болезни имеет доступ ко всем записям для всех отделов, это указывает на наличие иерархии, поэтому для меток защиты строк лучше использовать тип ДЕРЕВО (TREE).

Пользовательские метки защиты для менеджеров

Соответствующие метки защиты, назначаемые строкам, предоставляются менеджерам отделов для обеспечения доступа к данным своего отдела. Менеджеры имеют доступ к данным с правом ЧТЕНИЯ (READ), за исключением конфиденциальных столбцов.

Компоненты меток защиты

Необходимы два компонента меток защиты.

Для меток защиты столбцов требуется компонент меток защиты типа SET, с одним элементом 'CONFIDENTIAL'.

Для меток защиты строк требуется компонент меток защиты типа TREE, с корневым элементом 'LIFE_INS_DEPT', в качестве дочерних элементов используются имена отделов 'K01', 'K02', 'S01', 'S02'.

Рис. 5. Компонент метки защиты типа TREE

В следующем разделе показано, как реализовать спроектированное решение с помощью команд SQL.

Реализация решения по обеспечению безопасности

Обзор этапов:

1. Определение правил и меток защиты;
2. a. Определение компонентов меток защиты;
3. b. Определение правила защиты;
4. c. Определение меток защиты.
5. Изменение таблицы MEDICAL_RECORD с помощью добавления столбца меток защиты для защиты на уровне строк, маркирования конфиденциальных столбцов как защищенных и назначения таблице правила защиты.
6. Обновление столбца с метками защиты в таблице MEDICAL_RECORD.
7. Предоставление пользователям соответствующих меток защиты.

Этап 1: Определение правил и меток защиты

Требования к привилегиям и полномочиям

Для выполнения команд по созданию правил и меток защиты требуются полномочия SECADM.

Этап 1a: Определение компонентов меток защиты

На основе анализа требуется два компонента меток защиты. Компоненты меток защиты можно создать с помощью следующих команд:

					
        CREATE SECURITY LABEL COMPONENT SLC_LEVEL
             SET {'CONFIDENTIAL'}

        CREATE SECURITY LABEL COMPONENT SLC_LIFEINS_ORG
             TREE {'LIFE_INS_DEPT' ROOT,
             'K01' UNDER 'LIFE_INS_DEPT',
             'K02' UNDER 'LIFE_INS_DEPT',
             'S01' UNDER 'LIFE_INS_DEPT',
             'S02' UNDER 'LIFE_INS_DEPT'
             }
        

Этап 1b: Определение правила защиты

Следующий этап после создания компонентов меток защиты заключается в создании правила защиты. Правило защиты с именем MEDICAL_RECORD_ POLICY, использующее компоненты меток защиты SLC_LEVEL и SLC_LIFEINS_ORG, можно создать с помощью следующей команды:

        CREATE SECURITY POLICY MEDICAL_RECORD_POLICY
             COMPONENTS SLC_LEVEL, SLC_LIFEINS_ORG
             WITH DB2LBACRULES
             RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
        

Этап 1c: Определение меток защиты

На основе анализа необходимы следующие метки защиты:

1. Метка защиты столбцов.
2. Четыре метки защиты строк.
3. Пользовательская метка защиты для аналитиков истории болезни.

Метка защиты столбцов создается с помощью следующей команды:

        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MED_RECORD
             COMPONENT SLC_LEVEL 'CONFIDENTIAL'
        

Метки защиты строк создаются с помощью следующих команд:

        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_K01
             COMPONENT SLC_LIFEINS_ORG 'K01'
             
        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_K02
             COMPONENT SLC_LIFEINS_ORG 'K02'
             
        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_S01
             COMPONENT SLC_LIFEINS_ORG 'S01'
             
        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_S02
             COMPONENT SLC_LIFEINS_ORG 'S02'
        

Метка защиты для медицинских аналитиков создается с помощью следующей команды:

        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST
             COMPONENT SLC_LEVEL 'CONFIDENTIAL',
             COMPONENT SLC_LIFEINS_ORG 'K01', 'K02', 'S01', 'S02'
        

Этап 2: Создание защищенной таблицы SALES

Требования к привилегиям и полномочиям

ALTER (измените) привилегии таблицы MEDICAL_RECORD:

Администратору базы данных следует предоставить метку защиты, связанную с правилом защиты MEDICAL_RECORD_POLICY. Так как административная активность может потребовать работы с большинством строк и столбцов, можно рассмотреть вопрос предоставления максимальной метки защиты: MEDICAL_ANALYST. Изначально метка защиты администратора используется в качестве значения по умолчанию для нового столбца DEPARTMENT_TAG (см. Этап 3).

        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST
            TO USER <administrator_auth_id>
            FOR ALL ACCESS
        

Для защиты таблицы MEDICAL_RECORD все столбцы с конфиденциальной информация должны быть защищены меткой защиты MEDICAL_RECORD_POLICY.MED_RECORD. Для защиты строк добавляется новый столбец для хранения меток защиты. Таблицу можно защитить с помощью следующей команды:

        ALTER TABLE MEDICAL_RECORD
            ALTER COLUMN MEDICAL_HISTORY
                SECURED WITH MEDICAL_RECORD_POLICY.MED_RECORD
            ADD COLUMN DEPARTMENT_TAG DB2SECURITYLABEL
            ADD SECURITY POLICY MEDICAL_RECORD_POLICY
                

После успешного выполнения команды таблица MEDICAL_RECORD защищена.

Таблица 14. Определение таблицы MEDICAL_RECORD.

Этап 3: Обновление столбца меток защиты

Требования к привилегиям и полномочиям

Привилегия UPDATE для таблицы MEDICAL_RECORD:

Администратору базы данных можно предоставить метку защиты, которую можно использовать для обновлений (это сделано на этапе 2), или можно предоставить EXEMPTION (освобождение) для доступа с правом WRITE.

        GRANT EXEMPTION ON RULE DB2LBACWRITETREE
             FOR MEDICAL_RECORD_POLICY
             TO USER <administrator_auth_id>
        

Изначально столбец DEPARTMENT_TAG заполняется меткой защиты администратора (MEDICAL_RECORD_POLICY.MEDICAL_ANALYST), если таблица изменяется. Затем этот столбец необходимо обновить соответствующими метками защиты для каждой записи. Для этого используются следующие команды:

UPDATE MEDICAL_RECORD
        set DEPARTMENT_TAG= SECLABEL_BY_NAME ('MEDICAL_RECORD_POLICY', 'DEPT_K01')
        where DEPTNO='K01'

UPDATE MEDICAL_RECORD
     set DEPARTMENT_TAG= SECLABEL_BY_NAME ('MEDICAL_RECORD_POLICY', 'DEPT_K02')
     where DEPTNO='K02'

UPDATE MEDICAL_RECORD
     set DEPARTMENT_TAG= SECLABEL_BY_NAME ('MEDICAL_RECORD_POLICY', 'DEPT_S01')
     where DEPTNO='S01'

UPDATE MEDICAL_RECORD
     set DEPARTMENT_TAG= SECLABEL_BY_NAME ('MEDICAL_RECORD_POLICY', 'DEPT_S02')
     where DEPTNO='S02'             
        

Обновленная таблица MEDICAL_RECORD должна выглядеть следующим образом.

Таблица 15. Обвновленная таблица MEDICAL_RECORD

Этап 4: Предоставление пользователям меток защиты

Требования к привилегиям и полномочиям

Для выполения команд по предоставлению пользователям меток защиты требуются полномочия SECADM.

После защиты таблицы MEDICAL_RECORD пользователи без меток защиты не имеют доступа к этой таблице. Чтобы предоставить доступ к таблице Peter, Andrea и Joseph, предоставьте им метки защиты с помощью следующих команд:

        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY. MEDICAL_ANALYST
            TO USER PETER
            FOR ALL ACCESS

        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_K01
            TO USER Andrea
            FOR ALL ACCESS
            
        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_S02
            TO USER Joseph
            for ALL ACCESS
        

В следующем разделе показано, насколько хорошо действует решение LBAC по обеспечению безопасности.

Решение в действии

В данном разделе описаны некоторые сценарии, возможные после защиты таблицы MEDICAL_RECORD.

Пример 1

Аналитик истории болезни Peter пытается просмотреть таблицу MEDICAL_RECORD с помощью команды:

        SELECT * from INSURANCE.MEDICAL_RECORD;
        

Команда выполняется успешно. Возвращаются все записи MEDICAL_RECORD.

Пример 2

Andrea, менеджер отдела K01, пытается просмотреть таблицу MEDICAL_RECORD с помощью команды:

SELECT RECORDID, CLIENTNO, DEPTNO, APPLICATION_DATE, LAST_UPDATE, MEDICAL_HISTORY, RISK_INDEX 
             from INSURANCE.MEDICAL_RECORD;
        

Команда вызывает ошибку, потому что нарушает правило доступа на READ защищенного столбца MEDICAL_HISTORY.

Пример 3

Joseph, менеджер отдела S02, пытается манипулировать записью в таблице MEDICAL_RECORD. Сначала он выполняет запрос записи:

           SELECT RISK_INDEX from INSURANCE.MEDICAL_RECORD
           WHERE CLIENTNO='S231674';
        

Команда выполняется успешно. Возвращается значение RISK_INDEX.

Затем Joseph пытается обновить значение RISK_INDEX.

        UPDATE INSURANCE.MEDICAL_RECORD
             SET RISK_INDEX = 0
             WHERE CLIENTNO='S231674'
        

Команда вызывает ошибку, потому что нарушает ограничения доступа на чтение.
Если эту же команду выполняет Peter, она выполняется успешно, потому что Peter имеет право на запись в данные записи.

Пример 4

Joseph пытается обновить один из столбцов с конфиденциальной инфорацией в таблице MEDICAL_RECORD.

        UPDATE INSURANCE.MEDICAL_RECORD
             SET MEDICAL_HISTORY =''
             WHERE CLIENTNO='S231674'
        

Команда вызывает ошибку, потому что нарушает правило доступа к защищенному столбцу.

Заключение

На этом первая часть учебного руководства LBAC завершена. Теперь пользователь получил представление об основах защиты строк и столбцов и сможет разработать решение LBAC для защиты данных. Во второй части будут представлены более сложные сценарии и показано, как применять освобождения для управления защитой.