Перейти к содержанию
sbokov

Закрываем доступ к внешним носителям.

Recommended Posts

sbokov

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

В компании установлен SEP - в нем создал разные политики безопасности, раскидал народ по группам., т.е. осталось только применить и все будет работать., Но дабы не происходило непредвиденных событий, таких как, "у меня доступ должен быть, но его нет"

Прошу Вас дать комментарий, как Вы у себя на предприятии реализовывали. (Обзванивать всех - не вариант, 7 000 сотрудников)

p.s. В случае, если применить политику сразу ко всем, а потом по заявкам открывать доступ - вызовет нежелательный простой работы/потерю прибыли.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
strat

Все просто.

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

Иванов Петров - полный доступ

Сидоров - чтение

остальные - запрет

и все, т.ч. переложите работу на других, а у вас останется документ и при претензиях "Почему не работает" ткнете носом

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Зайцев Олег

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

Делается это так:

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

1.1. начальнику ИТ отдала [службы безопасности или кто там этим занимается] в срок до X подготовить политики безопасности, позволяющие [тут перечислить варианты, что они позволяют и блокируют] и протестировать их работу. По умолчанию к сотрудникам применяется такая-то политика, в случае, если требуется иное, то начальникам отделов в срок до X предоставить служебные записки с указанием сотрудников, которым требуется иной уровень доступа, причем с обоснованием необходимости

1.2 начальникам отделов в срок до X ознакомить персонал с тем, что вводятся политики и ограничения по использованию флешек. Информацию довести всем под роспись

1.3 начальнику ИТ отдала [службы безопасности или кто там этим занимается] в X+N ввести политику в действие

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

2. приказ выкладываем на ознакомление, если есть документооброт, то это делается одним ударом. Понятное дело, что 80% читать его не будет, потому логично продублировать его размещением на Интра-сайте (если он есть), сделать рассылку по почте. Я часто делаю мощнее - KAV WKS например умеет сообщения показывать с заданным текстом, полагаю в SEP есть что-то подобное. Можно в логон скрипт включить показ PDF с приказом - тоже неплохо. Для особо непонятливых я у себя в сети применял что-то типа самодельного SMS блокера - он запускается дистанционно, перекрывает собой экран без возможности разблокировки и висит минимум 60 секунд, и далее требует подтверждения, чтобы закрыться :) Выбор мер зависит от уровня исполнительности персонала и организованности

Важно то, что:

1. это приказ - т.е. потом не будет наездов, почему злодей-админ кому-то что-то разрешил, а кому-то запретил (ясное дело, что готовит его исполнитель), поломав тем самум бизнес-процесс. Если такое не сделать, то админ будет виноват в срыве всего, что можно списать на блокировку флешек

2. момент времени X должен быть отодвинут недели на 2 от момента подписания приказа - чтобы было достаточно время на то, чтобы познакомиться с приказом

3. начальники отделов ответственны за ознакомление персонала - если кто-то из их подчиненных не знаком, виноват будет начальник отдела, а не админ. Аналогично, если кто-то в отделе не получит нужного доступа, в нарушении бизнес-процесса будет виноват начальник, а не админ. Из практики могу сказать, что в среднем на 1к сотрудников от их начальников придет не более 10 служебок, и по ним несложно сделать настройку, а служебки подшить как обоснование и элемент документирования исключений (иначе через несколько месяцев при 7к сотрудников никто не вспомнит, почему Сидорову можно все, а Иванову - ничего)

4. задание жесткого интервала времени важно, иначе никто ничего не пришлет, а после включения политики будет лавина заявок

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

  • Upvote 15

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
strat

В очередной раз, видя пост волшебника из страны О.З. я наконец-то понял, что же мне это напоминает. Вот это

Ну невозможно продолжать тему после этого :) как будто бы уже сказали главный ответ о жизни вселенной и вообще :). 42 в общем.

Олег, ваш пост в любой теме может быть последним, т.к. добавить часто нечего.:)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
mvs

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

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

2) необходимо раз в год (в полгода) проводить аудит по приказам и изменениям.

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

Необходимо это если по каким то причинам у админов не сработала автоматизация (скрипты, политики и т.д.) , для того чтобы были боле менее актуальные списки и было чем "закрыться" перед IT аудиторами

И вообще все что касается так или иначе ИБ - должно быть строго регламентировано на предприятии:

1) Должны быть приказы по предприятию ( за подписью топ менеджемента, директора),

2) Регламенты действия приказов (для пользователей),

3) Утвержденные формы служебок (писем, заявок и т.д.)

4) Регламенты для IT служб (непосредственных исполнителей)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Создайте учетную запись или войдите, чтобы комментировать

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

×