Меню

Джонатан Хон

Рейтинг: 2200

Результат: 22 материала(ов)
Хон Джонатан

Сортировать:

Новое Популярное

Управление сертификатами и шифрование. SSL-сертификаты

Защита данных, передаваемых в систему SAP HANA и из неё, а также данных, которые хранятся в SAP HANA, является жизненно важной задачей. В этой главе представлены возможности SAP HANA для усиления безопасности системы: шифрование при обмене данными и шифрование на уровне данных для предотвращения несанкционированного доступа к системе и её данным.

Поддерживаемые сторонние поставщики аутентификации

SAP HANA поддерживает несколько надёжных сторонних механизмов аутентификации для реализации SSO. Это упрощает процесс аутентификации в SAP HANA из доверенных сторонних приложений. Однако в отличие от аутентификации по протоколу LDAP, в этом случае пользователи не могут пройти аутентификацию напрямую со своими сторонними паролями через SSO. При сторонней аутентификации пользователям не требуется вручную вводить своё имя пользователя и пароль повторно при каждом обращении к ресурсам на платформе SAP HANA. Система SAP HANA считает, что внешняя система уже провела корректную аутентификацию пользователя и поэтому доверяет запросам для пользователя из внешней системы. В SAP HANA поддерживается обращение из сторонних систем по протоколам HTTP, HTTPS, ODBC и JDBC. Это позволяет получать доступ к веб-приложениям и данным, размещённым на платформе SAP HANA. В этом разделе представлены сторонние механизмы аутентификации: Kerberos, SAML, X.509, тикеты регистрации SAP и тикеты подтверждения SAP, а также провайдеры идентификаторов JWT. Начнём с аутентификации через Kerberos.

Аутентификация, как ключевой элемент проверки для предоставления пользователю доступа к системе SAP HANA

Аутентификация — это ключевой элемент проверки для предоставления пользователю доступа к системе SAP HANA. В этой главе рассматривается механизм базовой внутренней аутентификации SAP HANA, а также поддержка внешних провайдеров аутентификации в SAP HANA.

Предоставление внешним объектам доступа к контейнерам HDI

При работе внутри контейнера HDI с помощью приложения SAP Web IDE for SAP HANA важно уделить должное внимание двум аспектам безопасности. Во-первых, разработчикам может потребоваться доступ к динамическим объектам каталога за пределами контейнера HDI и доступ к объектам в других контейнерах HDI. По умолчанию у разработчиков есть доступ только к объектам каталога в контейнере HDI или рабочем месте проекта.

Роли контейнеров HDI

По сути, роли контейнера HDI используются как основа для предоставления пользователям базы данных доступа к динамическим объектам в схеме контейнера HDI. После создания роли контейнера HDI на консоли SQL в проводнике баз данных SAP HANA можно выполнить специальные хранимые процедуры для предоставления ролей контейнера HDI пользователям. В этом разделе представлен обзор ролей контейнера HDI, описаны шаги для предоставления ролей контейнера HDI с помощью проводника баз данных SAP HANA и шаги для авторизации доступа EXECUTE для стандартного пользователя базы данных к хранимым процедурам в схеме #DI контейнера HDI.

Контейнеры HDI и безопасность в SAP HANA XSA

В архитектуре SAP HANA XSA разработка для SAP HANA осуществляется на уровне сервисов, который называется инфраструктурой развёртывания SAP HANA (SAP HANA Deployment Infrastructure, HDI). Аналогично SAP HANA XS или модели _SYS_REPO контейнеры HDI имеют время проектирования и время выполнения, но, как вы увидите, для HDI существуют некоторые различия. Рассмотрим подробнее архитектуру контейнера HDI в этом разделе.

Работа с SAP Web IDE for SAP HANA и компоненты для управления безопасностью

SAP Web IDE for SAP HANA представляет собой веб-приложение, которое размещается на платформе SAP HANA XSA и используется разработчиками для создания приложений для платформы SAP HANA XSA. С помощью приложения SAP Web IDE for SAP HANA разработчики могут создавать объекты каталога базы данных SAP HANA, ракурсы вычисления SAP HANA, артефакты CDS для SAP HANA и роли репозитория на базе SAP HANA XSA.

Управление доступом к областям, пользователями и коллекциями ролей в SAP HANA XSA

В SAP HANA разработка среды SAP HANA XSA структурирована по единицам, которые называются организациями и областями. Такая структура необходима для поддержки архитектуры приложений с несколькими целями (multi-target application, MTA). Архитектура MTA позволяет консолидировать разработку приложений, разделяя компоненты типичного решения для веб-приложений, размещённые на одной платформе. Большинство компонентов веб-приложений разрабатываются на разных языках программирования. С высокой степенью вероятности для каждого определена своя среда, функции управления жизненным циклом и отсоединённые сервисы операционной системы.

Безопасность в SAP HANA XSA

Усовершенствованная модель расширенных сервисов приложений SAP HANA (SAP HANA XSA) — следующий вариант классической модели расширенных сервисов приложений SAP HANA (SAP HANA XS). Новая платформа SAP HANA XSA предоставляет более надёжную среду сервера приложений с поддержкой нескольких сред выполнения и языков программирования.

Деактивация учётной записи SYSTEM в SAP HANA 2.0

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

Рекомендации по обеспечению безопасности в SAP HANA 2.0

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

Запрос системы для просмотра действующих полномочий в SAP HANA 2.0

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

Трассировка полномочий в SAP HANA 2.0

Трассировка полномочий является видом специфичной для пользователя трассировки. Она ограничивается подробным отслеживанием действий, выполняемых отдельной учётной записью пользователя. Специфичные для пользователей трассировки можно настроить для записи подробной информации о различных операциях в системе SAP HANA. Отслеживание можно проводить практически по всем компонентам SAP HANA. Полученные сведения используются для предоставления специфичной информации по выполняемым в системе SAP HANA операциям. Благодаря этому механизму трассировки администраторы безопасности могут сосредоточиться на контроле полномочий для выполнения операций.

Трассировка событий и устранение неисправностей в системе безопасности в SAP HANA 2.0

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

Запрос данных аудита в SAP HANA 2.0. Практический опыт: определение политик аудита в SAP HANA 2.0

Вы можете отправлять запросы в три основных системных ракурса, связанных с данными аудита и конфигурацией функцией аудита в SAP HANA. Эти ракурсы используются с самыми разными целями. В ракурсе действий на аудит можно просмотреть список всех действий, по которым может проводиться аудит в системе SAP HANA.

Создание политик аудита в SAP HANA 2.0

Как мы уже говорили выше, по умолчанию в системе SAP HANA аудит отключён. Кроме того, в системе нет готовых пользовательских политик аудита. Вы можете определить политики аудита, чтобы отслеживать специфичные события на основе указанных условий. Политики аудита определяются администратором аудита в зависимости от требований организации. В идеале компания должна записывать каждое событие в системе SAP HANA. Однако запись всех событий в базе данных с технологией in-memory — весьма затратное предприятие как с точки зрения финансов, так и с точки зрения архитектуры. Поэтому необходимо сконфигурировать конкретные политики аудита для записи только тех событий, которые являются критичными для обеспечения безопасности и стабильной работы системы.

Конфигурирование средств проведения аудита в SAP HANA 2.0

По умолчанию функции аудита в SAP HANA не активированы, а системы не настроены для фиксации специфичных событий в SAP HANA. В SAP HANA реализовано несколько интерфейсов для активации и настройки функций аудита. Наиболее широко используются интерфейсы в пульте управления SAP HANA и менеджере безопасности инструментальных средств SAP HANA для веб-разработки. Однако настроить политики аудита также можно с помощью SQL-операторов. Рассмотрим каждый из этих трёх инструментов подробнее.

Аудит в SAP HANA 2.0

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

Перенос пакетов средств безопасности SAP HANA 2.0 в другие системы SAP HANA

Как мы уже говорили, перенос модели безопасности между системами позволяет обеспечить согласованность при реализации модели безопасности в общем ландшафте SAP HANA. Чтобы эффективно использовать систему переноса в SAP HANA и достичь этой цели, необходимо определить в модели безопасности роли на базе репозитория. Если в основе модели безопасности лежат стандартные роли, созданные с помощью SQL-операторов, перенос такой модели между экземплярами SAP HANA будет невозможен.

1 2