The post has been translated automatically. Original language: Russian
Basic Cybersecurity Checklist for an IT startup: what to set up in the first month
Most hacks of small teams occur not because of complex attacks, but because of trivial gaps: a common password in Slack, open.env in the repository, a former employee with access to the production. I have put together a short checklist of what should be closed in the first month of the product's operation - without a budget for a separate security engineer.
1. Two-factor authentication wherever it is available
GitHub/GitLab, cloud console (AWS/GCP/Yandex Cloud), mail, payment services, domain registrar — wherever you can enable 2FA, enable it immediately. One compromised email password without 2FA is usually the way to all other services through access restoration.
2. Password manager for the whole team
Shared passwords in chat rooms and spreadsheets are not a question of "if", but a question of "when" a leak will occur. Any password manager with shared safes for the team closes this problem in one evening.
3. Secrets are not in the repository
.env files, API keys, and database access tokens regularly end up in git due to carelessness. Add it .env in .gitignore before the first commit, use git-secrets or a similar pre-commit hook that prevents you from committing a key-like string. If the secret has already leaked into the repository's history, it should be considered compromised and re—released: rewriting the history alone is not enough.
4. The principle of minimum access rights
Not everyone in the team should have access to the entire production infrastructure. Differentiate the roles: who can deploy, who can change the cloud configuration, and who can view logs with personal data. It also makes life easier when someone leaves the team - offboarding according to the checklist, rather than "I hope you remembered all the access points."
5. Backups according to the 3-2-1 rule
Three copies of the data, on two different media, one outside the main infrastructure (another region or provider). And a test recovery is required at least once a quarter: a backup that has never been deployed is highly likely not to recover when needed.
6. Automatic dependency checking
Dependabot, Snyk, or embedded analogues in GitHub/GitLab scan project dependencies for known vulnerabilities for free and open PR updates themselves. It is configured once in 15 minutes and then works in the background.
7. Basic logging and alerts
You don't need an expensive SIEM at the start — it's enough to log unsuccessful login attempts, access rights changes, and unusual traffic spikes, and set up at least one alert (for example, in Slack) for anomalies. This gives you a chance to notice the problem within hours, rather than learning about it from user complaints after a month.
8. Offboarding checklist
When a person leaves the team, deleting from Slack alone is not enough. We need a checklist: revoking access to repositories, cloud, database, corporate mail and payment services, and closing remote access to the internal infrastructure. It is better to keep it in the form of a template, which you simply mark point by point.
None of these items require a separate budget — just the time to set everything up once. For a team of 3-10 people, this set is usually enough to close most typical hacking scenarios at an early stage, while there are no resources for a full-fledged security function.
Чек-лист базовой кибербезопасности для IT-стартапа: что настроить в первый месяц
Большинство взломов небольших команд происходит не из-за сложных атак, а из-за банальных пробелов: общий пароль в Slack, открытый .env в репозитории, бывший сотрудник с доступом к продакшену. Собрал короткий чек-лист того, что стоит закрыть в первый месяц работы продукта — без бюджета на отдельного security-инженера.
1. Двухфакторная аутентификация везде, где она есть
GitHub/GitLab, облачная консоль (AWS/GCP/Yandex Cloud), почта, платёжные сервисы, домен-регистратор — везде, где можно включить 2FA, включайте сразу. Один скомпрометированный пароль от email без 2FA — это обычно путь ко всем остальным сервисам через восстановление доступа.
2. Менеджер паролей на всю команду
Общие пароли в чатах и таблицах — это не вопрос «если», а вопрос «когда» произойдёт утечка. Любой менеджер паролей с общими сейфами для команды закрывает эту проблему за один вечер.
3. Секреты — не в репозитории
.env-файлы, ключи API, токены доступа к базе данных регулярно попадают в git по невнимательности. Добавьте .env в .gitignore до первого коммита, используйте git-secrets или аналогичный pre-commit хук, который не даст закоммитить похожую на ключ строку. Если секрет уже утёк в историю репозитория — его нужно считать скомпрометированным и перевыпустить: одной перезаписи истории недостаточно.
4. Принцип минимальных прав доступа
Не у всех в команде должен быть доступ ко всей продакшен-инфраструктуре. Разграничьте роли: кто может деплоить, кто может менять конфигурацию облака, кто может смотреть логи с персональными данными. Это также упрощает жизнь, когда кто-то уходит из команды — офбординг по чек-листу, а не «надеюсь, вспомнили все доступы».
5. Бэкапы по правилу 3-2-1
Три копии данных, на двух разных носителях, одна — вне основной инфраструктуры (другой регион или провайдер). И обязательно тестовое восстановление хотя бы раз в квартал: бэкап, который ни разу не разворачивали, с большой вероятностью не восстановится, когда понадобится.
6. Автоматическая проверка зависимостей
Dependabot, Snyk или встроенные аналоги в GitHub/GitLab бесплатно сканируют зависимости проекта на известные уязвимости и сами открывают PR с обновлением. Настраивается один раз за 15 минут и дальше работает в фоне.
7. Базовое логирование и алерты
Не нужен дорогой SIEM на старте — достаточно логировать неудачные попытки входа, изменения прав доступа и необычные всплески трафика, и настроить хотя бы один алерт (например, в Slack) на аномалии. Это даёт шанс заметить проблему за часы, а не узнать о ней из жалоб пользователей через месяц.
8. Чек-лист офбординга
Когда человек покидает команду, одного удаления из Slack недостаточно. Нужен чек-лист: отзыв доступа к репозиториям, облаку, базе данных, корпоративной почте и платёжным сервисам, закрытие удалённого доступа к внутренней инфраструктуре. Лучше вести его в виде шаблона, который просто отмечаешь пункт за пунктом.
Ни один из этих пунктов не требует отдельного бюджета — только времени один раз всё настроить. Для команды из 3–10 человек этого набора обычно достаточно, чтобы закрыть большинство типичных сценариев взлома на ранней стадии, пока нет ресурсов на полноценную security-функцию.
Share
