Каждому свое. Методы разграничение доступа

Разграничение доступа

Рис.8.2. Стоимость и уровень технологий аутентификации

4. Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местоположению . Данный защитный механизм основан на использовании системы космической навигации типа GPS (Global Positioning System) . Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить местоположение пользователя. Аппаратура GPS проста и надежна в использовании и сравнительно недорога. Это позволяет применять ее в случаях, когда авторизованный удаленный пользователь должен находиться в определœенном месте.

Суммируя возможности механизмов и средств аутентификации, по уровню информационной безопасности выделим три вида аутентификации : 1) статическую; 2) устойчивую; 3) постоянную.

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

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

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

После выполнения идентификации и аутентификации крайне важно установить полномочия (совокупность прав) субъекта для последующего контроля санкционированного использования вычислительных ресурсов, доступных в АС. Такой процесс принято называть разграничением (логическим управлением) доступа .

Обычно полномочия субъекта представляются: списком ресурсов, доступным пользователю, и правами по доступу к каждому ресурсу из списка. В качестве вычислительных ресурсов бывают программы, данные, логические устройства, объём памяти, время процессора, приоритет и т.д.

Можно выделить следующие методы разграничения доступа : 1) по спискам; 2) с использованием матрицы установления полномочий; 3) по уровням секретности и категориям; 4) парольное.

1. При разграничении доступа по спискам задаются следующие соответствия: каждому пользователю – список ресурсов и прав доступа к ним или каждому ресурсу – список пользователœей и прав их доступа к данному ресурсу. Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в большинстве ОС и СУБД.

2. Использование матрицы установления полномочий предполагает применение матрицы доступа (таблицы полномочий). В указанной матрице строками являются идентификаторы субъектов, имеющих доступ в АС, а столбцами – объекты (информационные ресурсы) АС. Каждый элемент матрицы может содержать имя и размер предоставляемого ресурса, право доступа (чтение, запись и др.), ссылку на другую информационную структуру, уточняющую права доступа, ссылку на программу, управляющую правами доступа и др.
Размещено на реф.рф
(табл.8.3). Данный метод предоставляет более унифицированный и удобный подход, так как вся информация о полномочиях хранится в виде единой таблицы, а не в виде разнотипных списков. Недостатками матрицы являются ее возможная громоздкость и неоптимальность (большинство клеток – пустые).

Таблица 8.3

Разграничение доступа - понятие и виды. Классификация и особенности категории "Разграничение доступа" 2017, 2018.

После выполнения идентификации и аутентификации необходимо установить полномочия (совокупность прав) субъекта для последующего контроля санкционированного использования вычислительных ресурсов, доступных в АС. Такой процесс называется разграничением (логическим управлением) доступа.

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

Обычно выделяют следующие методы разграничения доступа:

Разграничение доступа по спискам;

Использование матрицы установления полномочий;

Парольное разграничение доступа.

При разграничении доступа по спискам задаются соответствия:

Каждому пользователю – список ресурсов и прав доступа к ним или

Каждому ресурсу – список пользователей и их прав доступа к данному ресурсу.

Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в большинстве ОС и СУБД.

Использование матрицы установления полномочий подразумевает применение матрицы доступа (таблицы полномочий). В указанной матрице (см. таблицу 2.7) строками являются идентификаторы субъектов, имеющих доступ в АС, а столбцами – объекты (информационные ресурсы) АС. Каждый элемент матрицы может содержать имя и размер предоставляемого ресурса, право доступа (чтение, запись и др.), ссылку на другую информационную структуру, уточняющую права доступа, ссылку на программу, управляющую правами доступа и др.

Таблица 2.7

Фрагмент матрицы установления полномочий

c – создание, d – удаление, r – чтение, w – запись, e – выполнение.

Данный метод предоставляет более унифицированный и удобный подход, т. к. вся информация о полномочиях хранится в виде единой таблицы, а не в виде разнотипных списков. Недостатками матрицы являются ее возможная громоздкость и не совсем оптимальное использование ресурсов (большинство клеток – пустые).

Разграничения доступа по уровням секретности и категориям состоят в том, что ресурсы АС разделяются в соответствии с уровнями секретности или категорий.

При разграничении по уровню секретности выделяют несколько уровней, например: общий доступ, конфиденциально, секретно, совершенно секретно. Полномочия каждого пользователя задаются в соответствии с максимальным уровнем секретности, к которому он допущен. Пользователь имеет доступ ко всем данным, имеющим уровень (гриф) секретности не выше, чем он имеет.

При разграничении по категориям задается и контролируется ранг категории, соответствующей пользователю. Соответственно, все ресурсы АС декомпозируют по уровню важности, причем определенному уровню соответствует некоторый ранг персонала (типа: руководитель, администратор, пользователь).

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

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

В завершении подраздела заметим, что руководящие документы могут регламентировать два вида (принципа) разграничения доступа:

Дискретное управление доступом;

Мандатное управление доступом.

Дискретное управление доступом представляет собой разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту. Данный вид организуется на базе методов разграничения по спискам или с помощью матрицы.

Мандатное управление доступом регламентирует разграничение доступа субъектов к объектам, основанное на характеризуемой меткой конфиденциальности информации, содержащейся в объектах, и официальном разрешении (допуске) субъектов обращаться к информации такого уровня конфиденциальности. Иначе, для реализации мандатного управления доступом каждому субъекту и каждому объекту присваивают классификационные метки, отражающие их место в соответствующей иерархии. С помощью этих меток субъектам и объектам должны быть назначены классификационные уровни, являющиеся комбинациями уровня иерархической классификации и иерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа. Ясно, что методы разграничения доступа по уровням секретности и категориям являются примерами мандатного управления доступом.

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

Что ж, сама по себе данная тема довольно грузная, и требует определённого времени на анализ и постанувку задачи.

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

Давайте с самого начала обсудим архитектуру модульной системы на выбранной нами псевдо-системе.

Все модули представлены ввиде подключаемых к главному документу (индекс-файлу) вставок. Запрос модуля происходит из строки запроса QUERY_STRING, и название подключаемого модуля передаётся в качестве аргумента act. В некотором месте индекса файла происходит изъятие и обработка данного параметра. После, если у пользователя достаточно прав для доступа к модулю в контексте чтения, происходит проверка существования указанного в строке запроса модуля, и если таковой существует, то происходит его подключение к индекс файлу.

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

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

Значение do буду фиксированными, данная переменная будет принимать следующие значения:

• main - главная часть модуля (доступно в контексте чтения)
• config - раздел настройки модуля (доступно в контексте записи)
• create - произвести некоторые действия, по добавлению информации в БД (доступно в контексте записи)
• delete - доступ к разделу, предоставляющему возможности удалить некоторую информацию, в контексте данного модуля (доступно в контексте записи)
• edit - доступ к редактированию информации в контексте модуля (доступно в контексте записи)

В целом, этот список можно увеличить, при этом всё зависит лишь только от масштабов проекта и его потребностей в функционале.

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

Так, запись о модуле системы будет содержать следующую информацию: английский идентификатор названия модуля, который будет идентичен значению переменной среды GET - act (относительно него будет производится непосредственно запрос модуля), русский идентификатор модуля, который будет использоватся в списке модулей.

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

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

Что ж, давайте рассмотрим эту особую структуру. Она будет следующей: [ module_indefier: + \: + \;] *

То есть идёт список из пар: имя модуля ":" права чтения "," права записи ";". При этом данная метка обновляется в момент внесения изменений о правах доступа пользователя к системе. Если в системе появляется информация о модуле, который не вошёл в данную метку, то стоит просто произвести процедуру редактирования, и данные сохранятся автоматически.

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

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

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

Таблица `modules`:

CREATE TABLE `modules` (`id` bigint(20) NOT NULL auto_increment, `indefier` text collate utf8_unicode_ci NOT NULL, `title` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Таблица `secure_groups`:

CREATE TABLE `secure_groups` (`id` bigint(20) NOT NULL auto_increment, `title` text collate utf8_unicode_ci NOT NULL, `perms` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

Таблица `users`

CREATE TABLE `users` (`id` bigint(20) NOT NULL auto_increment, `login` text collate utf8_unicode_ci NOT NULL, `passwd` text collate utf8_unicode_ci NOT NULL, `groupId` int(1) NOT NULL default "0", PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

temp=array(); $this->temp["_result"]=0; $this->temp["_uid"]=explode("::",$_COOKIE["site_hash"]); $this->temp["_uid"]=$this->temp["_uid"]; $this->temp["_gid"]=$this->getUserSecurityAccess($this->temp["_uid"]); $this->temp["_conn_id"]=mysql_connect("host","user","passwd"); mysql_select_db("database"); $this->temp["_q1"]=mysql_query("SELECT perms" ."FROM `secure_groups`" ."WHERE id=".$this->temp["_gid"]); $this->temp["_access_stamp"]=mysql_fetch_assoc($this->temp["_q1"]); $this->temp["_access_stamp"]=$this->temp["_access_stamp"]["perms"]; $this->temp["_access_stamp"]=explode(";",$this->temp["_access_stamp"]); $this->temp["_access_stamp"]=array_slice($this->temp["_access_stamp"],0,-1); foreach($this->temp["_access_stamp"] as $this->temp["v"]){ $this->temp["_mod_access"]=explode(":",$this->temp["v"]); $this->temp["_mod_indefier"]=$this->temp["_mod_access"]; if($this->temp["_mod_indefier"]==$module){ $this->temp["_perms"]=explode(",",$this->temp["_mod_access"]); switch($act){ case "r": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; case "w": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; } break; } } mysql_close($conn_id); return $this->temp["_result"]; } } ?>

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

Функция secure::getUserId()

Используя данную функцию, мы подразумеваем, что во время авторизации пользователя в системе в переменной среде $_COOKIE была установлена переменная `site_hash`, состоящая из идентификатора пользователя в системе и хеша для проверки аутентичности его в системе. Функция просто изымает значение идентификатора, возращая его значение на выходе.

Функция secure::getUserSecurityAccess($id)

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

Функция secure::checkUserPermission($module,$act))

Производится запрос к БД, относительно прав пользователя на произведение действий чтения/записи в контексте переданного в качестве параметра модуля.

Осталось лишь описать процедуру формирования переменной в среде $_COOKIE, и тему статьи можно будет считать расскрытой.

Процедура авторизации будет выглядеть ввиде внесения личных данных пользователя (логин и пароль) в специальную форму, после отправки которой произойдёт обработка данных, переданных пользователем, по-методу функции checkAuthData(), и, в случае корректности данных, будет произведено сохранение данных о пользователе ввиде куки записи на период установленный пользователем, либо в отсутствии заданного значение на период по-умолчанию.

Для проверки аутентичности данных хранимых в переменной среде $_COOKIE, мы будем использовать функцию EatCookie(), которая будет производить валидацию данных, возвращая булевый результат проверки (истина - ложь).

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

• `ulogin` - логин пользователя
• `upasswd` - пароль пользователя
• `stime` - время сессии, устанавливаемое пользователем (от 1 до 5 часов)
• `auth` - имя кнопки отправки

Вот, в целом и всё. Осталось лишь пробовать, экспериментировать, ошибатся и находить решение, что я всецело и оставляю вам.

Надеюсь, что мы скоро встретимся, а для тех кто имеет ко мне вопрос в отношении статьи, да и не только - писать на [email protected], либо на [email protected].

С уважением Карпенко Кирилл, глава IT-отдела ИНПП.

imbasoft 21 апреля 2016 в 00:04

Стандарт управления правами доступа к корпоративным файловым информационным ресурсам

• Информационная безопасность

Что может быть проще, чем разграничить права на папку в NTFS? Но эта простая задача может превратиться в настоящий кошмар, когда подобных папок сотни, если не тысячи, а изменение прав к одной папке «ломает» права на другие. Чтобы эффективно работать в подобных условиях, требуется определенная договоренность, или стандарт, который бы описывал, как решать подобные задачи. В данной статье мы как раз и рассмотрим один из вариантов подобного стандарта.

Сфера действия

Термины и определения

Основные принципы

1. Доступ разграничивается только на уровне каталогов. Ограничение доступа к отдельным файлам не проводится.
2. Назначение прав доступа выполняется на базе групп безопасности. Назначение прав доступа на отдельные учетные записи пользователей не проводится.
3. Явно запрещающие полномочия доступа (deny permissions) не применяются.
4. Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Чтение/Запись» / Everyone – Change).
5. При настройке сетевого доступа к файловому информационному ресурсу в настройках SMB/CIFS устанавливается опция «Перечисление на основе доступа (Access based enumeration)».
6. Создание файловых информационных ресурсов на рабочих станциях пользователей недопустимо.
7. Не рекомендуется размещать файловые информационные ресурсы на системных разделах серверов.
8. Не рекомендуется создавать несколько точек входа в файловый информационный ресурс.
9. Следует по возможности избегать создание вложенных файловых информационных ресурсов, а в случаях, когда имена файлов или каталогов содержат конфиденциальную информацию, это вовсе недопустимо

Модель разграничения доступа

• Доступ «Только на чтение (R ead O nly)».
• Доступ «Чтение и запись (R ead & W rite)».

Правила именования групп доступа пользователей

FILE-Имя файлового информационного ресурса–аббревиатура полномочий

Имя файлового информационного ресурса
должно совпадать с UNC именем ресурса или состоять из имени сервера и локального пути (если сетевой доступ к ресурсу не предоставляется). При необходимости в данном поле допускаются сокращения. Символы «\\» опускаются, а «\» и «:» заменяются на «-».

Аббревиатуры полномочий :

• RO - для варианта доступа «Только на чтение (Read Only)»
• RW - для варианта доступа «Чтение и запись (Read & Write)».

Пример 2
Имя группы доступа пользователей, имеющих полномочия «Чтение и запись» для файлового информационного ресурса, размещенного на сервере TERMSRV по пути D:\UsersData, будет:
FILE-TERMSRV-D-UsersData-RW

Шаблон прав доступа к каталогам файлового информационного ресурса

Таблица 1 – Шаблон NTFS-прав доступа для корневого каталога файлового информационного ресурса.

Бизнес процессы управления доступом к файловым информационным ресурсам

1. Создаются группы доступа пользователей. Если сервер, на котором размещен файловый информационный ресурс, является членом домена, то создаются доменные группы. Если нет, то группы создаются локально на сервере.
2. На корневой каталог и промежуточные каталоги файлового информационного ресурса назначаются права доступа согласно шаблонам прав доступа.
3. В группы доступа пользователей добавляются учетные записи пользователей в соответствии с их полномочиями.
4. При необходимости для файлового информационного ресурса создается сетевая папка (shared folder).

В. Изменение доступа пользователя к файловому информационному ресурсу
Учетная запись пользователя перемещается в другую группу доступа пользователей в зависимости от указанных полномочий.

Г. Блокирование доступа пользователя к файловому информационному ресурсу
Учетная запись пользователя удаляется из групп доступа пользователей файлового информационного ресурса. Если работник увольняется, то членство в группах не меняется, а блокируется учетная запись целиком.

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

1. В группы доступа пользователей вложенного файлового информационного ресурса добавляются группы доступа пользователей вышестоящего составного файлового информационного ресурса.

1. Регистрируется вложенный файловый информационный ресурс (согласно процессу А)
2. В группы доступа пользователей создаваемого информационного ресурса помещаются те учетные записи пользователей, которым требуется предоставить доступ.

1. Организационными (или техническими, но не связанными с изменением прав доступа к каталогам файловой системы) мерами блокируется доступ пользователей к данному и всем вложенным файловым информационным ресурсам.
2. К корневому каталогу файлового информационного ресурса назначаются новые права доступа, при этом заменяются права доступа для всех дочерних объектов (активируется наследие).
3. Перенастраиваются права доступа для всех вложенных информационных ресурсов.
4. Настраиваются промежуточные каталоги для данного и вложенных информационных ресурсов.

Примеры

Подготовка файлового сервера
На диске «D:» сервера «FILESRV» создаем каталог «D:\SHARE\». Этот каталог будет единой точкой входа во все файловые информационные ресурсы, размещенные на данном сервере. Организуем сетевой доступ к данной папке (используем апплет «Share and Storage Management»):

Решение.
В каталоге «D:\SHARE\» сервера «FILESRV» создадим папку «D:\SHARE\Отдел разработки информационных систем\», которая будет корневым каталогом для файлового информационного ресурса. Также создадим группы доступа пользователей (глобальные группы безопасности домена «ICS») для данного ресурса:

• «FILE-FILESRV-SHARE-Отд. разр. ИС-RO»
• «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Каталог D:\SHARE\ является точкой входа и промежуточным каталогом для данного ресурса. Добавим в него права на проход (Traverse) для групп: «FILE-FILESRV-SHARE-Отд. разр. ИС-RO» и «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»


Дамп NTFS разрешений, полученных командой cacls:


NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

Поскольку пользователям требуется доступ на чтение и запись, добавим их учетные запаси в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Предоставление доступа пользователю к файловому информационному ресурсу
Постановка задачи.
Предположим, в отдел разработки приняли еще одного работника – специалиста Егорова Михаила Владимировича ([email protected]), и ему, как и остальным работникам отдела, требуется доступ на чтение и запись к файловому информационному ресурсу отдела.

Решение.
Учетную запись работника необходимо добавить в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Создание вложенного информационного ресурса. Расширение доступа
Постановка задачи.
Предположим, Отдел разработки информационных систем решил улучшить качество взаимодействия с Отделом маркетинга и предоставить руководителю последнего - Кругликовой Наталье Евгеньевне ([email protected]) - доступ на чтение к актуальной документации на продукты, хранящейся в папке «Документация» файлового информационного ресурса Отдела разработки информационных систем.

Решение.
Для решения данной задачи необходимо сделать вложенный ресурс «\\FILESRV\share\Отдел разработки информационных систем\Документация», доступ к которому на чтение и запись должен быть (остаться) у всех пользователей, имевших доступ к «\\FILESRV\share\Отдел разработки информационных систем\ и добавиться доступ на чтение для пользователя Кругликовой Натальи Евгеньевне ([email protected])

В каталоге «D:\SHARE\Отдел разработки информационных систем\» создадим папку «D:\SHARE\Отдел разработки информационных систем\Документация», которая будет корневым каталогом для нового ресурса. Также создадим две группы доступа пользователей:

• «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO»
• «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

Поскольку всем пользователям, имеющим доступ в «\\FILESRV\share\Отдел разработки информационных систем\», необходим аналогичный доступ в \\FILESRV\share\Отдел разработки информационных систем\Документация», то добавим группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RO» в «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO» и «FILE-FILESRV-SHARE-Отд. разр. ИС-RW» в «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW» соответственно. Добавим учетную запись Кругликовой Натальи Евгеньевны ([email protected]) в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

Теперь, если Кругликова Наталья Евгеньевна ([email protected]) обратится по ссылке «\\FILESRV\share\Отдел разработки информационных систем\Документация», то она сможет попасть в интересующую ее папку, но обращаться по полному пути не всегда удобно, поэтому настроим сквозной проход к данной паке от точки входа «\\FILESRV\share\» («D:\SHARE\»). Для этого настроим права доступа на промежуточные каталоги «D:\SHARE\» и «D:\SHARE\Отдел разработки информационных систем\».

Проведем настройку «D:\SHARE\»:


Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R


NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

И «D:\SHARE\Отдел разработки информационных систем»:


Дамп NTFS разрешений, полученных командой cacls:

ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R

ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

Создание вложенного информационного ресурса. Сужение доступа
Постановка задачи
В целях организации резервного копирования наработок Отдела разработки информационных систем начальнику отдела Иванову Сергею Леонидовичу ([email protected]), в рамках файлового информационного ресурса отдела, понадобилась сетевая папка «Архив», доступ к которой был бы только у него.

Решение.
Для решения данной задачи в файловом информационном ресурсе отдела требуется сделать вложенный ресурс «Архив» («\\FILESRV\share\Отдел разработки информационных систем\Архив»), доступ к которому предоставить только начальнику отдела.

В каталоге «D:\SHARE\Отдел разработки информационных систем\» создадим папку «D:\SHARE\Отдел разработки информационных систем\Архив», которая будет корневым каталогом для нового ресурса. Также создадим две группы доступа пользователей:

• «FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO»
• «FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW»

«D:\SHARE\Отдел разработки информационных систем»


Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R


ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

И «D:\SHARE\»:


Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW:R
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

Учетную запись пользователя Иванова Сергея Леонидовича ([email protected]) добавим в группу FILE-FILESRV-Отд. раз.ИС-Архив-RW.

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

Разграничение доступа пользователей

Разграничение прав доступа пользователей сети - это настройки, связанные с сегментированием на отдельные части и определение правил взаимодействия этих частей друг с другом. Если говорить техническим языком, это процесс создания VLAN для каждого конкретного подразделения, и настройки доступности этих VLAN между собой.

VLAN (Virtual Local Area Network) - это виртуальное разделение сети на части (локальные сети). По умолчанию, коммутатор, считает все свои интерфейсы (порты) в одной и той же локальной сети. С помощью дополнительной конфигурации, можно создавать отдельные подсети и выделять определенные порты коммутатора для работы в этих сетях. Лучшим определением VLAN можно считать то, что VLAN - это один широковещательный домен.

Разграничение прав доступа пользователей требуется, когда в Вашей организации есть ресурсы, которые предназначены для конкретных специалистов (бухгалтерские отчеты, например). Тем самым, можно создать отдельный VLAN для специалистов из бухгалтерии, запретив доступ к отчетности из других подразделений.

Ограничение доступа в социальные сети

Если вы не хотите, чтобы Ваши сотрудники имели доступ к конкретным ресурсам (социальным сетям, запрещенным сайтам), мы можем предложить 4 доступных способа это сделать:

— Запретить доступ локально на конкретном ПК. Сделать это можно через файл /etc/hosts.

— Настройка ACL (Access Control List) на граничном маршрутизаторе. Смысл заключается в запрете доступа из конкретной подсети, к конкретным адресам.

— Настройка DNS (Domain Name System) сервера. Суть метода, в запрете разрешения конкретных доменных имен. Это означает, что при вводе в адресную строку браузера сайта vk.com, например, данное доменное имя не будет преобразовано в IPv4 адрес, и пользователь не сможет зайти на этот сайт.

— Специальное ПО. Мы предлагаем специальное (антивирусное) ПО от наших партнеров.

Сетевая безопасность

Порой, даже случайно открытая web - страница в интернете, может нести угрозу всей корпоративной сети, содержа в себе вредоносный код. Именно для подобных случаев, мы предлагаем воспользоваться решениями от лидеров рынка информационной ИТ безопасности - наших партнеров.

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

Фишинг - метод кибератак, при котором главной целью является заполучение данных авторизации пользователей. Например, это могут быть данные логина и пароля для входа в личный кабинет банка, данные от SIP - аккаунта и так далее.

Специализированное программное обеспечение от наших партнеров обеспечит высокий уровень информационной безопасности:

— Защита информации на персональных компьютерах.

— Обеспечение безопасности хранения данных на серверах.

— Защита информации в рамках облачных решений.

Статистика безопасности

"Лаборатория Касперского" и B2B International провели исследования, согласно которому, 98,5% компаний МСБ (малого и среднего бизнеса) подвергались внешним кибер - угрозам. Из них 82% испытали на себе действие внутренних угроз.

Компании МСБ (малого и среднего бизнеса) теряют 780 тыс. рублей от одного случая нарушения информационной безопасности на предприятии.

Поможем

Статистика оставляет желать лучшего, но бояться не стоит. Обеспечение мер защиты с помощью решений от наших партнеров закроет уязвимости в корпоративной сети.

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

План работ

Исследуем Вашу текущую сетевую инфраструктуру