Перейти к содержанию
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 служб (непосредственных исполнителей)

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


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

  • Сообщения

    • Ego Dekker
    • ArktiTig
      Арктика - северная полярная область Земли, включающая окраины материков Евразии и Северной Америки, почти весь Северный Ледовитый океан с островами и прилегающие к нему части Атлантического и Тихого океанов. Название её происходит от греческого слова arctos (медведь) и связано со звёздами: Полярная звезда, находящаяся почти точно в зените над Северным полюсом, принадлежит к созвездию Малая Медведица.
    • ArktiTig
      Арктика - северная полярная область Земли, включающая окраины материков Евразии и Северной Америки, почти весь Северный Ледовитый океан с островами и прилегающие к нему части Атлантического и Тихого океанов. Название её происходит от греческого слова arctos (медведь) и связано со звёздами: Полярная звезда, находящаяся почти точно в зените над Северным полюсом, принадлежит к созвездию Малая Медведица.
    • PR55.RP55
      .xml  файлы taskschd.msc Могут быть подписаны  цифровой подписью. Думаю будет нелишним, если uVS будет это фиксировать. т.е. проверять не только подпись целевого файла, но и подпись самого файла\задачи. и писать в ИНфО .  
    • demkd
      ---------------------------------------------------------
       4.15.2
      ---------------------------------------------------------
       o Исправлена ошибка при работе с образом автозапуска.
         Для некоторых процессов команда unload не добавлялась в скрипт при нажатии кнопки "принять изменения".  o Добавлена плашка окна на таскбаре для окна удаленного рабочего стола.
         (при работе с удаленной системой) -----------------------------------------------------------
      Есть проблема с локализацией глюка в редких случаях приводящему к аварийному завершению uVS при активном флаге "Проверять весь HKCR".
      На основе дампов его найти не получается, нужна копия реестра системы с такой проблемой, если кому-то попадется такая проблема, то присылайте архив с копией реестра системы мне на почту.  
×