Как указать файлы за которыми должна следить система

Обновлено: 04.07.2024

Противостояние изменениям - основная черта человека. Если в то время, когда вы начинали работу с системами контроля версий, не было Git - весьма вероятно, что вы начинали с Subversion. Часто люди говорят, что Git слишком сложен для начинающих. Тем не менее, я позволю себе с вами не согласиться.

В этой статье я расскажу, как можно использовать Git в работе с вашими проектами. Будем считать, что вы создаете проект с нуля, и хотите использовать Git в качестве системы контроля версий. После ознакомления с основными командами, мы ознакомимся с тем, как можно выложить ваш код на GitHub.

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

Установка Git

На официальном сайте Git есть подробная информация о его установке на различные системы - Linux, Mac, Windows. В нашем случае мы будем использовать Ubuntu 13.04, и Git мы будем устанавливать посредством apt-get .

Начальная конфигуация

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

Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init , которая создает директорию .git со всей информацией о вашем проекте.

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

Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.

Также мы устанавливаем цвет интерфейса в значение auto , так что вывод команд Git будет цветным. Мы добавляем префикс --global к этим командам для того, чтобы эти значения использовались во всей системе, и не было необходимости их задавать для каждого отдельного проекта.

Готовим файлы для коммита

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

Проверяем состояние репозитария

Теперь, когда в вашем проекте есть файлы, давайте посмотрим, как Git с ними обращается. Чтобы проверить текущий статус репозитария, используйте команду git status

Добавляем файлы в Git

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

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

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

Можно использовать git add рекурсивно, но будьте осторожны с этой командой. Есть некоторые файлы (например, скомпилированные программы), которые не должны быть добавлены в систему контроля версий. Если вы используете git add рекурсивно, такие файлы также попадут в репозитарий.

Удаляем файлы

Представим, что вы случайно добавили в репозитарий файл, который не должен был туда попасть. Или же вы хотите убрать из системы контроля версий какой-либо файл. В общем, команда git rm не просто удалит файл из репозитария, но и физически удалит его с диска. Чтобы Git перестал отслеживать файл, но он остался на диске, используйте следующую команду:

Коммитим изменения

Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом 8dd76fc .

Дальнейшие коммиты

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.

Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff . Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff <файл> .

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

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

Управление проеком

Чтобы просмотреть историю проекта, можно воспользоваться следующей командой:

где <хеш_коммита> - шестнадцатеричный номер, ассоциированный с коммитом. Так как данное руководство предназначено новичкам, мы не будем рассматривать, как вернуть состояние на момент конкретного коммита, или как управлять ветками.

5 последних уроков рубрики "Разное"

Как выбрать хороший хостинг для своего сайта?

Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг - это будущее Ваших сайтов

Разработка веб-сайтов с помощью онлайн платформы Wrike

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

20 ресурсов для прототипирования

Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

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

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

Что такое GIT?

Преимущества GIT

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

откат к определенной точке в разработке;
логирование (ведение журнала) изменений в проекте;
быстрое и удобное обновление файлов на сервере (сравнивал на личном опыте, это удобней FTP загрузки);
возможность командной разработки.

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

Как работает GIT?

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

Для начала работы с GIT необходимо создать репозиторий. Есть несколько типов репозиториев: стандартные и пустые (bare). Основное отличие заключается в том, что в пустом репозитории не расположены сами файлы, а в его настройках может быть указана папка для развертывания (деплой, deploy, применения изменений в существующие файлы), но об этом также расскажу дальше.

А также внесем следующие параметры для Windows:

Теперь вернемся к командной строке GIT (GIT Bush) и запомним некоторые основные комманды GIT:

UPD: для проверки истории вашего репозитория вы можете воспользоваться командой git log. Для навигации используйте клавиши стрелка влево/стрелка вправо. Однако она не очень удобна в использовании в таком формате.

Теперь при вводе в любом репозитории команды git hist мы сможем увидеть подобного вида историю операций над нашим проектом. Также зайдите в папку .git после всех проделанных операций и посмотрите на файл config, в нем вы увидите что параметры конфигурации делятся на группы (alias, core).

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

Есть вопрос? Что-то не понятно в статье? Хочешь отблагодарить? Пиши комментарий!
Если тебе понравилась статья, а тем более если еще и помогла - поставь +1 и нажми "Мне нравится"!

В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt

3. Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

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

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

В компании произошел неприятный инцидент – в общем доступе оказалась справка о здоровье одного из топ-менеджеров. Эта ситуация заставила начать разбираться: как такое могло произойти? К какой еще информации имеют доступ посторонние? Как далеко уходят документы? На каких компьютерах без учета и внимания хранятся персональные данные, «файлики» с паролями, документы с грифом «комтайна»? Какие неучтенные копии черновиков приказов выходят за пределы круга доверенных лиц?

С такими вопросами компания ставила на тест FileAuditor, российскую DCAP-систему Сканирование файловых хранилищ

FileAuditor ведет непрерывный мониторинг файлов и папок, чтобы оперативно выявлять изменения в них.

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

Агенты FileAuditor незаметны для пользователей, не тормозят контролируемые машины благодаря настройкам:

расписания проверок (например, только по окончании рабочего времени);

условия проверок (например, только если загрузка ЦП меньше N%, только в отсутствии активных сессий и т.д.);

скорости сканирования (ее можно снизить для облегчения нагрузки на инфраструктуру).

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

Рис. 2. Вся информация о ходе вычитки каталогов с файлами доступна на вкладке «Статистика сканирования»

Классификация данных

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

Искать эти признаки программа может:

По ключевым словам, фразам и последовательности символов (иноязычные вставки, @, №, $, % и т.д.). Поддерживается поиск ключевых слов с морфологией, т.е. в измененных формах. Можно уточнить поиск, указав, сколько раз в документе должны встречаться искомые слова и фразы. Если искать сразу несколько ключевых слов, можно задать, какое расстояние в документе между ними допустимо, чтобы считать сочетание значимым.
По словарям. В программе есть встроенный редактор, который автоматически преобразует в готовый словарь любой текст-образец, загружаемый пользователем. Этот вид поиска полезен для выделения тематических категорий документов: например, считать файл попадающим в категорию «финансовые документы», если в нем встретилось не менее 5 выражений из словаря бухгалтерской терминологии.
По регулярным выражениям. Можно создавать сложные регулярные выражения, когда в одном поиске скомбинированы несколько условий. Например, учитывать в правиле классификации только файлы, где одновременно встречаются не менее 5 комбинаций из номеров карты и трехзначных CVC/CVV-кодов. Кроме того, можно сразу убедиться, что запрос работает корректно: доступно поле проверки, где можно задать пример искомой комбинации символов и протестировать, распознает ли его система.
По атрибутам. Критерий позволяет относить к правилу классификации только файлы определенного типа, размера, созданные или измененные в заданном интервале, хранящиеся в определенной директории и т.д.

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

Вся значимая информация в пределах компании будет рассортирована по категориям – «Офисные файлы», «Контракты», «Прайсы», «Персональные данные» и т.д. Система обнаружит все файлы, относящиеся к ним, где бы они ни находились, и поставит на них соответствующие «метки».

Рис. 4. Цветная маркировка правил и подсветка ключевых фрагментов документа в FileAuditor

Архивирование критичных документов

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

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

Аудит прав доступа

FileAuditor определяет права доступа пользователей к каждому документу благодаря вычитке сведений из ресурсов файловой системы. Программа видит:

перечень групп и конкретных сотрудников, которым доступен файл;

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

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

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

Рис. 5. Наиболее полная информация о пользовательских разрешениях доступна в отчетах

«Права доступа к ресурсам» и «Владельцы ресурсов». Последний особенно полезен, чтобы проконтролировать появление новых объектов в файловой системе и распределить права доступа к ним.

Контроль действий пользователей

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

Рис. 6. Просмотр операций с файлом в FileAuditor

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

Например, можно выбрать только документы, которые в заданный промежуток времени:

были изменены;

переименованы;

получили новые настройки прав доступа;

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

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

Рис. 7. Расследование инцидента в FileAuditor: сотрудник изменил содержимое документа, чтобы он перестал попадать под правило, и переместил его в папку «Не забыть унести»

Управление инцидентами

Политики безопасности в FileAuditor помогают вовремя среагировать на нежелательные события с заданными категориями данных. Настроить автоматизированный поиск нарушений можно:

по категории файла или папки (в соответствии с правилами классификации);

по пользовательским правам доступа;

по дате создания или изменения и т.д.

Например, можно создать политику, которая оповестит, если новые пользователи получили расширенные права доступа к документам из категории «Финансовая отчетность». Или если с документа снят гриф «коммерческая тайна».

Рис. 8. Сработка политики безопасности FileAuditor: новые пользователи получили права на редактирование контролируемого документа

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

Блокировка по меткам как возможность защитить файлы

В FileAuditor реализованы блокировки по меткам – возможность запрещать доступ и пересылку конфиденциальных файлов в любых произвольных приложениях.

Например, в FileAuditor можно запретить отправку файлов с меткой «ПДн» по любому каналу – будь то корпоративный мессенджер или Telegram. Пользователь просто не сможет прикрепить такие документы во вложения и получит уведомление об ошибке. Можно разрешить работу в MS Office с документами из категории «Конфиденциально» только директору – тогда все остальные пользователи, даже получив доступ к такому файлу, не смогут его открыть.

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

Огромное значение метки имеют для работы DLP, их наличие позволяет системе обеспечить мгновенную блокировку утечек конфиденциальных данных, потому что теперь защитной системе не нужно проверять содержимое каждого файла. Чтобы понять, насколько критичен документ, DLP теперь достаточно проверить его метку. Это еще и не перегружает систему. Блокировка по меткам реализована в DLP-системе «СёрчИнформ КИБ».

Преимущества «СёрчИнформ FileAuditor»

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

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

Доступность. FileAuditor доступнее зарубежных аналогов. Ключевые зарубежные DCAP-системы доступны только крупным корпорациям и не по карману другим заказчикам. Кроме того, многие зарубежные продукты более требовательны к ресурсам, громоздки, что находит отражение в нагрузке на кадры и затратах на железо.

Русскоговорящая техподдержка рядом. Если у заказчика возникнут вопросы во время разворачивания системы или при работе, скорость ответа имеет решающее значение. Клиенты «СёрчИнформ», знакомые с работой менеджеров внедрения, инженеров, техподдержки, отмечают работу наших специалистов как одно из ключевых преимуществ при выборе вендора.

Возможность интеграции. FileAuditor легко интегрируется с другими продуктами «СёрчИнформ», в первую очередь с DLP «СёрчИнформ КИБ». Как говорилось выше, это существенно повышает уровень защиты информации, т.к. обеспечивается защита не только данных «в покое» (с помощью FileAuditor), но и «в движении» (что отслеживает DLP).

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

Читайте также: