Планирование безопасности для любой внедряемой системы Microsoft Dynamics AX помогает защитить активы компании и обеспечить безопасность системы в будущем. Кроме того, таким образом можно оценить допустимый уровень риска по безопасности и документально оформить любые согласованные компромиссы.

Любая система, которая проектируется для клиента, должна отвечать стандартным рекомендациям корпорации Майкрософт по безопасности корпоративного приложения. Дополнительные сведения о рекомендациях по настройке инфраструктуры с продуктами корпорации Майкрософт см. в разделе Приступая к работе со связанными технологиями.

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

Этот раздел также описывает Факторы, которые следует учитывать для шифрованиядля взаимодействия клиент/сервер и хранилища базы данных.

Управление безопасностью

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

Чтобы в приложении Microsoft Dynamics AX можно было включить пользователей в форме Microsoft Dynamics AX, все эти пользователи должны быть перечислены в службах каталогов Microsoft Active Directory на контроллере домена. Это позволяет добавить дополнительный уровень безопасности к компьютерной среде. Если пользователь не включен в упомянутой выше форме, доступ к Microsoft Dynamics AX ему не предоставляется.

По умолчанию отдельные пользователи не имеют доступа к ресурсам Microsoft Dynamics AX, таким как формы, данные и отчеты. Необходимо назначить пользователей одной или нескольким группам, а затем назначить этим группам соответствующие разрешения. Чтобы еще точнее отрегулировать доступ, можно сгруппировать несколько компаний в домены и использовать безопасность на уровне записи.

Рекомендации

Ниже приводятся рекомендации по управлению безопасностью доступа:

  • Документальное оформление и обсуждение соответствующих политик и процедур для безопасности инфраструктуры и безопасности приложения Microsoft Dynamics AX как в отделе информационных технологий, так и в отделах пользователей организации должны стать частью бизнес-процессов.

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

  • Стоит подумать о шифровании взаимодействия клиент-сервер и конфиденциальной информации, хранящейся в базе данных. Подробные сведения об аспектах шифрования см. в разделе Факторы, которые следует учитывать для шифрования.

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

  • Прямой доступ к базе данных Microsoft Dynamics AX должны иметь только администраторы приложения. Сведения об управлении доступом можно найти в документации к конкретной базе данных.

  • Не следует устанавливать Business Connector на компьютер клиента Microsoft Dynamics AX для Windows, если только это не требуется для интеграции с приложениями сторонних производителей.

Дополнительные сведения о структуре Microsoft Dynamics AX с точки зрения безопасности см. в разделе Обзор архитектуры безопасности. Дополнительные сведения по настройке безопасности приложения см. в справке администратора.

Требования к домену для развертывания корпоративного портала с доступом из Интернета

Если требуется обеспечить доступ внешних пользователей к корпоративному порталу, для этих внешних пользователей необходимо настроить доменные учетные записи. Дополнительные сведения по настройке веб-пользователей см. в справке администратора. Место расположения доменных учетных записей для внешних пользователей зависит от структуры пограничной сети. Дополнительные сведения о пограничной сети см. в разделе Топология пользователей Active Directory.

Правила

Следуя нескольким простым правилам администрирования, можно повысить безопасность среды Microsoft Dynamics AX.

  • Пользователям Microsoft Dynamics AX не требуются административные привилегии в домене, поэтому все учетные записи пользователей Microsoft Dynamics AX должны принадлежать к четко определенным ограниченным группам пользователей. Кроме того, согласно принципу наименьших привилегий, все пользователи системы Microsoft Dynamics AX должны иметь минимальные права. Это начинается на уровне домена. Необходимо создать доменную учетную запись пользователя, которая будет использоваться при работе Microsoft Dynamics AX.

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

  • Необходимо ограничить количество пользователей, которые входят в группу Администраторы. По умолчанию эта группа имеет доступ ко всем полям, таблицам, отчетам и модулям в Microsoft Dynamics AX. Пользователи, ставшие членами группы Администраторы, смогут просматривать отчеты или данные, которые они, возможно, просматривать не должны, или изменить конфигурации и бизнес-логику в системе. Рекомендуется включать в группу Администраторытолько тех сотрудников, которые настраивают и администрируют систему Microsoft Dynamics AX. Права доступа в группе Администраторыне могут быть изменены.

  • При определении уровней разрешений необходимо работать совместно с менеджерами, контролирующими различные группы пользователей в компании или организации. Например, чтобы задать уровни разрешений для группы или групп "Финансы", обратитесь к начальнику финансового отдела. Этот руководитель знает, какие группы должны иметь разрешения на доступ к таким элементам, как Главная книгаи Банк, включая разрешения на доступ к дочерним узлам.

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

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

  • При изменении разрешений для группы пользователей, особенно если уровень разрешений понижен, нужно попросить пользователей в этой группе выйти из системы, а затем снова войти в нее. Если пользователи не сделали этого, предыдущие разрешения могут продолжать действовать до перезапуска клиентского приложения. Рекомендуется просить членов группы выйти из системы Microsoft Dynamics AX до изменения разрешений. Если это необходимо, перед началом изменения разрешений для группы пользователей можно проверить Права групп пользователей( Администрирование> Обычные формы > Активные пользователи), чтобы просмотреть список активных пользователей.

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

Обеспечение конфиденциальности в Microsoft Dynamics AX

При внедрении системы Microsoft Dynamics AX сотрудничество с группой внедрения позволяет обеспечить защиту личных данных, хранящихся в системе, в соответствии с законами и постановлениями соответствующих стран.

Личные данные включают в себя любые сведения, относящиеся к соответствующему лицу или позволяющие его идентифицировать. Такие сведения могут включать в себя фамилию, страну или регион проживания, домашний адрес, адрес электронной почты, номер кредитной карты, страховой номер (SSN), государственный идентификационный номер, IP-адрес или любой уникальный идентификатор, связанный с личными данными в какой-либо другой системе.

Сбор личных данных

Если выбрана отправка отчетов об ошибках в корпорацию Майкрософт, личные данные могут быть непреднамеренно собраны системой Microsoft Dynamics AX. Такие данные не будут использоваться для идентификации сотрудников компании. С политикой сбора данных, на которой основана работа модуля Microsoft Error Reporting, можно ознакомиться на веб-узле интерактивного анализа сбоев (Microsoft Online Crash Analysis).

Можно также выбрать сбор личных данных с помощью системы Microsoft Dynamics AX у клиентов, сотрудников или поставщиков в рамках используемых бизнес-процессов. Личные данные можно собирать непосредственно у клиентов, регистрирующихся на корпоративном портале, или этим может заниматься сотрудник от имени клиента или другого сотрудника.

Хранение личных данных

Личные данные можно хранить в базе данных Microsoft Dynamics AX. В следующем списке перечислены некоторые (но не обязательно все) таблицы, в которых могут содержаться личные данные:

  • любая таблица, начинающаяся с BANK;

  • любая таблица, начинающаяся с COMMISSION;

  • COMPANYINFO;

  • CONTACT;

  • CUSTTABLE;

  • EMPLTABLE и любая другая таблица, начинающаяся с EMPL;

  • ECPCUSTSIGNUP;

  • любая таблица, начинающаяся с HRM;

  • SYSCOMPANYUSERINFO;

  • USERINFO;

  • VENDTABLE.

См. также