Обзор CyberArk Privileged Account Security Solution 9.6
В обзоре рассматривается решение для управления привилегированными учетными записями и контроля доступа привилегированных пользователей CyberArk Privileged Account Security Solution 9.6, разработанное израильской компанией CyberArk Software Ltd. В материале представлены архитектура решения, его функциональные возможности и описание основных интерфейсов компонентов системы.
Сертификат AM Test Lab
Номер сертификата: 164
Дата выдачи: 06.06.2016
Срок действия: 06.06.2021
Данные для проведения технического обзора предоставлены официальным дистрибьютором компании CyberArk, на территории России и стран СНГ, компанией Softprom by ERC. Запросите демонстрацию отправив запрос по ссылке в конце статьи.
Введение
Проблема, связанная с управлением привилегированными учетными записями, актуальна, пожалуй, для каждой крупной компании. Привилегированными называют учетные записи, которые предоставляют доступ к системе с очень широкими полномочиями. Такие учетные записи имеются практически в каждой IT-системе: это может быть учетная запись ROOT на серверах Linux и VMware ESXi, учетная запись Administrator на рабочих станциях и серверах операционных систем семейства Microsoft Windows, общие учетные записи SAP, Cisco, Oracle и многие другие.
Контролировать привилегированные учетные записи сложно — как организационно, так и технически. Управление и контроль еще больше затрудняются, если пользователи являются сотрудниками внешних организаций, например: инженеры системных интеграторов, разработчики программного обеспечения, специалисты технической поддержки. Риски, связанные с несанкционированным использованием привилегированных учетных записей, очень высоки, так как вероятность их использования и ущерб от них гораздо больше и реальнее.
Для снижения рисков, связанных с использованием привилегированных аккаунтов, необходимы специализированные решения, которые обеспечат автоматизированное управление учетными записями и постоянный контроль действий привилегированных пользователей.
Рынок решений для контроля привилегированных пользователей сейчас активно развивается. На нашем сайте уже неоднократно публиковались обзоры и сравнения игроков рынка решений для контроля над привилегированными учетными записями. Одному из таких решений — CyberArk Privileged Account Security 9.6 — посвящен этот обзор.
Состав модулей CyberArk Privileged Account Security 9.6
Система управления привилегированными учетными записями CyberArk Privileged Account Security Solution 9.6 — решение корпоративного класса, ориентированное на крупные центры обработки данных (локальные и облачные), а также на OT/SCADA-среды.
Решение является комплексным и включает в себя ряд модулей:
Каждый модуль является автономным и может функционировать независимо от других. Работая вместе, модули обеспечивают законченное комплексное решение.
Рисунок 1. Состав модулей CyberArk Privileged Account Security Solution 9.6
Основными (базовыми) и наиболее востребованными на рынке являются модули Enterprise Password Vault и Privileged Session Manager, поэтому в обзоре подробно будут рассматриваться именно они.
Архитектура CyberArk Privileged Account Security
«Ядром» системы CyberArk Privileged Account Security является модульная платформа CyberArk Shared Technology Platform. На базе модульной платформы построены все компоненты CyberArk Privileged Account Security Solution.
Рисунок 2. Архитектура решения
Enterprise Password Vault предоставляет сервис управления жизненным циклом паролей на любых целевых системах: приложения, базы данных, Windows/Linux системы и др. Enterprise Password Vault позволяет защищать, управлять, автоматически менять пароли и сохранять лог всех действий со всеми типами привилегированных учётных записей. Работа с Enterprise Password Vault осуществляется через веб-интерфейс Password Vault Web Access.
Решение CyberArk Privileged Account Security Solution имеет «безагентскую» архитектуру — не требует развертывания агентов защиты на конечных системах.
CyberArk Privileged Account Security Solution также поддерживает интеграцию со следующими типами систем:
Типовая схема работы с CyberArk Privileged Account Security Solution
Типовая схема работы с модулями Enterprise Password Vault и Privileged Session Manager в архитектуре CyberArk Privileged Account Security Solution выглядит следующим образом:
Рисунок 3. Типовая схема работы CyberArk Privileged Account Security Solution
Системные требования и поддерживаемые технологии
Особенных требований CyberArk Privileged Account Security Solution не предъявляет: компоненты устанавливаются на серверные версии операционных систем Microsoft Windows Server (2008, 2012), а для управления CyberArk Privileged Account Security Solution достаточно любого современного веб-браузера.
Однако стоит отметить, что для установки хранилища Digital Vault требуется отдельный выделенный сервер и машина не должна быть членом домена, а для работы с Privileged Session Manager требуется установка сервиса Remote Desktop Services и покупка необходимого количества лицензий для удаленного подключения пользователей (RDS CAL License).
CyberArk Privileged Account Security Solution поддерживает широкий спектр протоколов и клиентов для инициации привилегированных сеансов. Ниже приведен перечень поддерживаемых управляемых устройств и платформ:
Далее в обзоре будут подробно рассмотрены основные функциональные возможности Enterprise Password Vault и Privileged Session Manager, а также работа с указанными модулями.
Основные функциональные возможности CyberArk Privileged Account Security Solution
Основные функциональные возможности Enterprise Password Vault
Для начала будут рассмотрены основные функциональные возможности модуля Enterprise Password Vault из состава CyberArk Privileged Account Security:
Основные функциональные возможности Privileged Session Manager
Основными функциональными возможностями модуля Privileged Session Manager из состава CyberArk Privileged Account Security являются:
Работа с CyberArk Privileged Account Security Solution
Рассмотрим типовой сценарий работы с CyberArk Privileged Account Security Solution на примере предоставления безопасного доступа внешнему пользователю (например, инженеру системного интегратора) для подключения к FTP-серверу организации с использованием клиента FileZilla.
Работа с CyberArk Privileged Account Security Solution начинается с авторизации на портале Password Vault Web Access. В веб-браузере необходимо набрать URL: http:// /passwordvault. После ввода появляется стартовая страница Password Vault Web Access, на которой можно выбрать тип аутентификации для входа в систему.
Рисунок 4. Стартовая страница Password Vault Web Access
После выбора метода аутентификации необходимо ввести аутентификационной данные и авторизоваться в системе. В рассматриваемом примере используется метод аутентификации Active Directory.
Рисунок 5. Авторизация на портале Password Vault Web Access
При входе в систему пользователь видит рабочую область, на которой отображаются основные элементы управления в зависимости от его роли. В общем случае, интерфейс CyberArk предоставляет для работы следующее меню:
В нашем случае для пользователя IT Guy доступен только раздел меню «Учетные записи», который содержит перечень доступных для него привилегированных учетных записей целевых систем. Например, для доступа к FTP-серверу компании, пользователь должен выбрать привилегированную учетную запись ftpuser.
Рисунок 6. Перечень доступных учетных записей для пользователя IT Guy на портале Password Vault Web Access
После выбора учетной записи пользователь переходит в меню «Данные учетной записи».
Для подключения к целевой системе с использованием привилегированной учетной записи пользователю необходимо выбрать в меню «Данные учетной записи» клиента доступа. Например для подключения к FTP-серверу пользователь выбирает FTP-клиент FileZilla. При этом стоит отметить, что пользователю доступ к паролю привилегированной учетной записи запрещен, поэтому он не может его просмотреть или узнать. Пользователю разрешено только подключение с использованием привилегированной учетной записи. Пароль привилегированных учетных записей неизвестен никому и периодически, в зависимоти от заданных политик безопасности, меняется автоматически системой.
Рисунок 7. Выбор клиента для подключения к FTP-серверу на портале Password Vault Web Access
Для подключения к целевой системе также необходимо согласовать доступ с ее владельцем. Чаще всего эту роль выполняет администратор информационной безопасности.
Для этого пользователю необходимо заполнить форму запроса доступа с указанием промежутка времени проведения работ и причины, которая может быть выбрана из заранее настроенного списка. Для проведения срочных работ, может быть предоставлен код экстренного доступа.
Рисунок 8. Создание запроса на доступ в Password Vault Web Access
Администратор информационной безопасности получает уведомление по почте о запросе на доступ. В рассматриваемом примере это запрос от пользователя IT Guy на доступ к FTP-серверу компании c использованием привилегированной учетной записи ftpuser. Для разрешения доступа к конечной системеАдминистратору необходимо согласовать запрос на подключение.
Рисунок 9. Согласование администратором запроса на доступ к FTP-серверу в Password Vault Web Access
После согласования Администратором доступа к FTP-серверу компании пользователь устанавливает FTP-соединение с использованием учетной записи ftpuser и клиента Filezilla.
Рисунок 10. Подключение к FTP-серверу через портал Password Vault Web Access
Во время FTP-сессии пользователь может выполнять различные действия, например, ввод команд.
Рисунок 11. Работа на FTP-сервере (ввод комманд)
Для мониторинга и контроля за действиями привилегированных пользователей необходимо авторизоваться на портале Password Vault Web Access используя учетную запись с привилегиями Аудитора.
Рисунок 12. Вход в пользователя с полномочиями аудитора на портал Password Vault Web Access
Аудитор в разделе меню «Данные учетной записи» может просматривать все действия, совершенные от имени учетной записи ftpuser, включая введенные пользователем команды.
Рисунок 13. Мониторинг действий, совершенных от имени учетной записи ftpuser, в Password Vault Web Access
В разделе меню «Мониторинг» можно выполнить поиск сессий, в которых были выполнены определенные команды. Например, можно найти те сессии, в которых была выполнена команда «Anti Malware».
Рисунок 14. Поиск открытых сессий с командой «Anti Malware» в меню «Мониторинг» в Password Vault Web Access
В меню «Данные совместного сеанса» Аудитор может ознакомится с подробным описанием сессии, в том числе ознакомиться с полным списком выполненных команд.
Рисунок 15. Просмотр данных о текущей FTP-сессии в Password Vault Web Access
Аудитор через меню «Данные совместного сеанса» также может подключиться к открытой сессии и осуществлять мониторинг в режиме «реального времени».
Через меню «Данные совместного сеанса» Аудитор также может принудительно завершать привилегированные сессии.
Рисунок 16. Мониторинг сессии в режиме «реального времени» в Password Vault Web Access
После завершения сессии в меню «Свойство записи» Аудитору доступны видео фрагменты, привязанные к конкретным командам, совершенным во время сессии.
Рисунок 17. Свойства записи FTP-сессии в Password Vault Web Access
Аудитор также может просматривать лог сессии в текстовом формате. При этом в лог будут включены все нажатые клавиши и выполненные команды пользователем. Данные логов также могут быть отправлены в системы класса SIEM для автоматической корреляции.
Рисунок 18. Просмотр лога сессии в текстовом формате в Password Vault Web Access
У Аудитора также есть возможность выгрузить полностью видеозапись сессии и просматривать ее в любом удобном проигрывателе. На видеозапись могут быть наложены ограничения, например, она может быть защищена от просмотра другими аудиторами.
Рисунок 19. Просмотр видеозаписи сессии в Password Vault Web Access
После завершения привилегированной сессии пароль привилегированной учетной записи автоматически изменяется на новый. Даже если во время сессии с помощью программно-технических средств пароль был украден, он уже не может быть использован повторно для входа в систему, так как в системе пароль уже автоматически изменен на новый.
Во вкладке «Версии» можно посмотреть сведения об изменениях пароля для привилегировнной учетной записи.
Рисунок 20. Просмотр сведений об автоматических сменах паролей в Password Vault Web Access
Выводы
В данном обзоре мы познакомились с комплексным решением для управления привилегированными учетными записями CyberArk Privileged Account Security Solution 9.6, подробно рассказали об основных, наиболее востребованных на рынке модулях, входящих в состав решения: Enterprise Password Vault и Privileged Session Manager. При этом в состав CyberArk Privileged Account Security Solution 9.6 входят и другие интересные модули: On-Demand Privileges Manager (управление и непрерывный мониторинг команд), Privileged Threat Analytics, Application Identity Manager (контроль встроенных учетных привилегированных записей в приложения), CyberArk Viewfinity Enables (исключение у пользователей бизнес-подразделений прав локальных администраторов), SSH Key Manager (управление SHH-ключами). Но о них мы поговорим в следующих обзорах.
CyberArk Privileged Account Security Solution 9.6 представляет собой мощный набор инструментов для автоматизации контроля и управления действиями привилегированных пользователей. Это также подтверждается и в обзоре Market Guide for Privileged Access Management аналитического агентства Gartner. Стоит отметить, что CyberArk Privileged Account Security Solution занимает лидирующие позиции на международном рынке и пользуется хорошим спросом. Об этом мы уже подробно рассказывали в обзоре «Контроль привилегированных пользователей (PUM) — обзор мирового и российского рынка».
Одним из ключевых преимуществ решения CyberArk Privileged Account Security Solution является его модульная архитектура. Модульность позволяет клиентам внедрять только те модули, в которых есть потребность. В случае необходимости расширения функционала системы контроля клиент может просто докупить необходимые модули и лицензии и с легкостью их интегрировать в уже функционирующую инфраструктуру безопасности CyberArk.
Также к сильным сторонам продукта относятся: широкий спектр поддерживаемых целевых систем, клиентов доступа, протоколов, методов аутентификации, широкие возможности мониторинга действий администраторов.
К явным недостаткам можно отнести отсутствие у рассматриваемой версии продукта сертификатов соответствия требованиям безопасности ФСТЭК России и отсутствие технической документации на русском языке.
Отсутствие сертификатов может являться существенным ограничением при использовании продукта в организациях государственного сектора, а также во многих частных компаниях. Более ранние версии продуктов CyberArk уже сертифицировались ФСТЭК России — программный комплекс CyberArk Privileged Identity Management and Session Management Suite 8.0 имеет сертификат ФСТЭК России на соответствие Техническим условиям № 3267, действителен до 24.11.2017г.
Отсутствие технической документацией может затруднить работу с системой, если пользователи плохо владеют иностранными языками.
Достоинства:
Недостатки:
Cyberark conjur что это
This repository guides you through a sample installation of Conjur Open Source using Docker Compose.
This repo is a Community level project. It’s a community contributed project that is not reviewed or supported by CyberArk. For more detailed information on our certification levels, see our community guidelines.
To follow this quick start guide, you will need to install Docker Toolbox.
You will also need to clone this repository to your working directory:
Using this quick start with Conjur Open Source
We strongly recommend choosing the version of this project to use from the latest Conjur OSS suite release. Conjur maintainers perform additional testing on the suite release versions to ensure compatibility. When possible, upgrade your Conjur version to match the latest suite release; when using integrations, choose the latest suite release that matches your Conjur version. For any questions, please contact us on Discourse.
Step by step guide
In the sections below, we’ll walk through standing this environment up step by step. Alternatively, you can follow the instructions by visiting the web tutorial: https://www.conjur.org/get-started/quick-start/oss-environment/.
Set up a Conjur Open Source environment
In this unit you will learn how to install Conjur OpenSource using Docker.
At the end of this section: You will have a working Conjur Open Source environment with a Conjur account and an admin user.
Pull the Docker images
Verification When the required images are successfully pulled, the terminal returns the following:
Generate the master key
The master data key will be used later to encrypt the database. In the working directory, generate the key and store it to a file:
* Tip: Although not mandatory, we prefer to store sensitive data to a file and not to display it directly on console screen.
The data key is generated in the working directory and is stored in a file called data_key.
Verification When the key is generated, the terminal returns the following:
Load master key as an environment variable
Load data_key file content (the master data key) as an environment variable:
Start the Conjur Open Source environment
Start the Conjur Open Source environment:
When Conjur Open Source starts, the terminal returns the following:
Verification Run the following command to see a list of running containers:
Create an admin account
Create a Conjur account and initialize the built-in admin user.
An account named myConjurAccount is created and the admin user is initialized, following keys are created and stored at admin_data file:
Connect the Conjur client to the Conjur server
This is a one-time action. For the duration of the container’s life or until additional initcommand is issued, the Conjur client and the Conjur server remain connected.
Use the account name that you created in step 5:
Verification The terminal returns the following output:
In this unit you will learn how to load your first policy. Formatted in YAML, policy defines Conjur entities and the relationships between them. An entity can be a policy, a host, a user, a layer, a group, or a variable.
A sample application policy named BotApp.yml is provided in the client container under policy directory.
At the end of this section: As a privileged user, you will load a policy that defines a human user, a non-human user that represents your application, and a variable.
Log in to Conjur as admin
Log in to Conjur as admin. When prompted for a password, insert the API key stored in the admin_data file:
Verification When you successfully log in, the terminal returns:
Load the sample policy
Load the provided sample policy into Conjur built-in root policy to create the resources for the BotApp:
Conjur generates the following API keys and stores them in a file, my_app_data:
Those API keys is correlated with the number of Users & Hosts defined in a policy.
Verification The terminal returns:
Verification When you successfully log out, the terminal returns:
In this unit you will learn how to store your first secret in Conjur.
Log in as Dave, the human user. When prompted for a password, copy and paste Dave’s API key stored in the my_app_data file:
Verification To verify that you logged in successfully, run:
The terminal returns:
Generate a value for your application’s secret:
This generates a 12-hex-character value.
Store the generated value in Conjur:
A policy predefined variable named BotApp/secretVar is set with a random generated secret.
Verification The terminal returns a message:
In this unit you will learn how to program an application to fetch a secret from Conjur using the REST API.
At the end of this section: You will know how to leverage Conjur’s ability to store your application’s secrets securely.
Start a bash session
Enter the BotApp container.
Generate a Conjur token
Generate a Conjur token to the conjur_token file, using the BotApp API key:
The Conjur token is stored in the conjur_token file.
Run program to fetch the secret:
The secret is displayed.
TIP: If the secret is not displayed, try generating the token again. You have eight minutes between generating the conjur token and fetching the secret with BotApp.
Congratulations! You are ready to secure your own apps with Conjur.
Now that you’ve got a local Conjur instance running, what can you do with it?
Try some of our tutorials on Conjur.org.
Explore the Conjur database
This section is about exploring the database. The admin panel from pgAdmin can be used to discover and explore the database schema, stored procedures and triggers that constitute a significant part of the inner working of Conjur. It offers a glimpse into the data model of Conjur.
This section should follow only after completion of the Store a secret section. There’s more insight to be gleamed from the database when it has become reasonably populated with some representative data i.e. roles, identities, permissions etc.
To explore the database
Configuring Conjur with predefined admin password
The following command will allow you to specify the admin user’s password:
The password must be provided via STDIN in any manner you prefer and must meet the following complexity rules:
Note: This feature is available in Conjur v1.11.5+
Using persistent Conjur configuration
With small variations to the steps outlined above, it is possible to set up a Conjur Open Source environment that retains Conjur configuration or state across Docker container restarts. Using the steps outlined below, a Conjur Open Source environment can be set up that uses a local directory on the host to persist Conjur configuration across container restarts.
Set up a Conjur Open Source environment with persistence
If you are already running the Conjur Open Source quickstart environment without persistence, bring down the associated containers:
Create a directory for storing persistent state. For example:
NOTE: The permissions on this directory will automatically be changed to 700 by docker-compose when the directory gets host-mounted by the Conjur container.
Modify docker-compose.yml in this repository to support persistent storage of Conjur state. Add the following line to the bottom of the database service configuration, replacing
with the path to the directory created in the previous step:
Start the Conjur Open Source environment using persistence:
Restarting the Conjur Open Source environment using persistence
Once you have set up the Conjur Open Source environment to support persistent Conjur state, you can restart your environment as follows:
Bring the containers down:
NOTE: You must use the docker-compose down command here rather than the docker-compose stop in order to avoid having stale, ephemeral connection state in the Conjur container. If you use the docker-compose stop command here instead, you may see errors as described in the Failed to open TCP connection error for Conjur login section below.
Bring the containers back up:
Reconnect the Conjur client to the Conjur server. Use the account name that you created in the Create an admin account section above. For example:
Log in again to Conjur as admin. When prompted for a password, insert the API key stored in the admin_data file:
Verification When you successfully log in, the terminal returns:
Delete the Conjur data directory when done
For added security, remember to delete the data directory that you created in Step 1 of the Set up a Conjur Open Source environment with persistence section above.
Adding or Modifying Container Environment Variables
This section describes the process of either adding or modifying environment variables for a docker-compose service. The process recreates a service with the desired changes, while the rest of the system continues running. Note that for a stateful service, there should be a persistence mechanism in place (e.g. volume mounts), otherwise data will be lost when the container is recreated.
The example below will add an environment variable CONJUR_LOG_LEVEL=debug to the conjur service container.
Add or modify environment variables in docker-compose.yml
docker-compose.yml is used to define the Conjur Open Source system. Additions and modifications to environment variables are made in the environment configuration of the desired service, and are of the form:
Recreate the container
Verify that the desired environment variables are now defined in the container
If the environment variable was correctly assigned in the container, the terminal returns the value of the variable:
Failed to open TCP connection error for Conjur login
If you are using persistent Conjur configuration, and you see the following error when trying to log into Conjur:
Then try the following:
Run the following command:
If the command in Step 1 produces the following line:
To recover from this, run:
And log in again, e.g.:
If «A server is already running» does not show in the Conjur container logs, or Step 2 above is unsuccessful, then try restarting all containers:
and try logging in again, e.g.:
We welcome contributions of all kinds to this repository. For instructions on how to get started and descriptions of our development workflows, please see our contributing guide.
About
Start securing your secrets and infrastructure by installing Conjur, using Docker and the official Conjur containers on DockerHub.
