Loading...

Карта рисков

  • Мониторинг

    • ресурсы серверов

      • диск

      • CPU

      • память

      • сеть/траффик

    • состояние проектов

      • аптайм сервисов

      • валидность сертификатов?

    • хостинг сайтов

      • аптайм сайтов

      • настройки DNS

      • валидность и срок сертификата

    • автоматизация

      • регистрация доменов в мониторинге

      • регистрация серверов в мониторинге

      • реестр ресурсов которые необходимо мониторить

    • внутренние сервисы

  • Человеческий фактор

    • утечка/контроль паролей и доступов

      • Авторизация через passkey

      • Аудит на интеграцию с openid

      • Требование обязательного наличия openid в проектах

      • Сотрудники имеют доступы к системам клиентов

      • Сотрудники передают пароли/токены/секреты в открытом виде в чатах/задачах/почте и прочих "публичных" местах

      • ограничение доступа к авторизации в сервисы на уровне keycloak

      • антивирус у сотрудников

      • аудит логинов пользователей (раз в год), так же надо добавить логирование всех входов через кейклок

    • Bus-фактор

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

      • Сотрудники имеют доступ к управлению учетными записями в платформе Perxis и других системах

    • Работа с парольным менеджером

      • ограничить доступы в bearpass, запретить создание в корне

      • реорганизовать структуру хранения паролей в bearpass

  • Резервное копирование

    • Валидация резервных копий

    • Что копировать

      • Базы данных

      • Файлы проектов на дисках

      • Файлы в объектных хранилищах

      • Хостинг сайтов (статика)

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

  • Общее

    • Реестр систем которые хранят/обрабатывают ПД

    • Реестр внешних систем используемых в проектах

    • Регламенты и гайдлайны

      • Требования по контролю устаревших или временных данных

        • Срок хранения ПД

        • Периоды очистки ПД

        •  В приложении должны быть политики очистки устаревших данных

        • Политика работы с временными файлами

      • Требования по поддержке интеграций в проектах

        • поддержка OpenID в любой админке любого проекта где админкой будут пользоваться наши сотрудники

        • Поддержка вывода логов в json для обеспечения удобства сбора в систему логирования

          • Персональные данные и секреты должны маскироваться

      • Регламентировать сроки отключения legacy-проектов

      • Требования к оформлению

      • Соглашение об именовании переменных, адресов и т.д.

    • Внутренние сервисы и тестовые окружения доступны публично

      • Тестовые сайты

        • Закрыть паролем

        • Запретить индексацию технических доменов

      • Develop-окружения

      • Внутренние сервисы

  • Проекты

    • PERXIS

      • Авторизация

        • Два сервера авторизации

          • Миграция пользователей auth.perx.ru -> auth.perxis.ru

        • Много сотрудников имеют доступ к панели управления пользователями

          • Ограничить круг лиц имеющих доступ к административной панели keycloak

          • Регистрация пользователя в keycloak по приглашению?

        • регуляоная проверка авторизаций

      • Concourse

        • Кластер на  baremetal

      • Платформа

        • Две отдельных установки

          • Слияние БД

          •  Слияние s3

        • Большой размер БД

          • Кластер БД

        • Сценарий восстановления / отката базы данных

        • Завязка на гитлаб для сборок сайтов

          • Файлы темы клонируются из репозитория

          • Образы для сборок берутся из реестра гитлаба

            • yandex registry

            • self-hosted  registry как сервис для Perxis

      • Деактивация аккаунтов при отсутствии активности

    • Legacy проекты

      • no one cares

  • Инциденты и восстановление

    • Порядок регистрации и описания решений инцидентов

    • Отработка сценария восстановление в случае инцидента

  • Внутренние сервисы

    • Self-hosted Gitlab

      • мониторинг ресурсов сервера и аптайм

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

    • Yandex.Tracker

      • Расширенные отчеты от сторонней компании

    • Yandex 360

      • ограниченная доступность данных на пользовательских дисках

      • Диск

        • Подумать про резервные копии содержимого общих дисков

        • Внедрить общие диски вместо шаринга от пользователей

    • Unisender

      • возможная утечка ПД, альтернативы

        • sendsay.ru

        • rusender.ru

        • yandex postbox (пока в бете)

      • блокировка по спаму

    • Mattermost

      • мониторинг ресурсов и аптайм

    • Docker registry / NPM registry и прочие пакетные менеджеры

      • Блокировка

        • Nexus?

        • План действий на случай блокировки по подготовке сервера с пакетами

    • Keycloak

      • проблема пересечения логинов из-за однофамильцев, нужна новая схема логинов/email

        • обсудить с менеджерами

    • Политика обновлений сервисов

  • ИБ

    • Пункт: “Внедрение соответствующей системы менеджмента информационной безопасности” означает, что у Обработчика (то есть у вас) должна быть структурированная система управления безопасностью информации (СМИБ), а не просто «разовые меры» вроде антивируса или фаервола.

      ⸻

      📌 Что именно подразумевается:

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

      Если проще: это “организационный каркас”, который делает так, чтобы безопасность была не случайной, а управляемой, регулярной и проверяемой.

      ⸻

      ✅ Обычно это включает:
      1. Политику информационной безопасности — документ, где прописаны цели, подходы, ответственность, контроль и принципы защиты информации.
      2. Ответственные лица за ИБ (в вашем случае уже назначен Юнкин Д.Г.).
      3. Процедуры управления доступом, инцидентами, обновлениями, шифрованием, аудитом.
      4. Журналы учета доступа, логирования, нарушений и проверок.
      5. Обучение сотрудников (хотя бы инструктаж по базовым угрозам и правилам).
      6. Периодические внутренние проверки/аудиты — даже простыми чек-листами.
      7. (По желанию) — сертификация по стандарту ISO 27001 или его внутреннее соответствие.

      ⸻

      🎯 Что от вас хочет Клиент:

      Чтобы у вас:
      • была понятная, зафиксированная структура и процессы по ИБ;
      • вы могли показать, что управление безопасностью — это не хаос, а система;
      • вы могли при необходимости предоставить подтверждение: например, политику безопасности, назначение ответственного, план проверок и т.п.

      ⸻

      Если у вас такой системы пока нет, но есть отдельные элементы — можно:
      • Объединить их в один документ (например, “Положение об информационной безопасности”);
      • Назначить ответственного (уже есть);
      • Составить план проверок, контрольных точек, и описать процесс управления доступом/инцидентами.

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

  • Отказоустойчивость

    • Gitlab

      • Repository

      • Registry

    • Keycloak