Как обезопасить свой бекенд от разработчиков?

Всем привет!
Есть проект. Есть программисты. Работаем.

К примеру, в дальнейшем что-то не поделили/поругались, всякое может быть.
И потом бэкендер говорит, что я могу тебе поломать сайт, если ты... шантажирует, короче.

Обывательский пример. Он запрятал кусок кода, что если на сайт входит юзер с ником xxx, то удалить всю базу данных пользователей. И таких вот пасхальных яиц может понаставить в разных местах.

Моя компетентность не позволяет мне исследовать php-код на наличие таких уязвимостей.

Что делать? Как доверять сердце своего проекта незнакомых людям? Да пусть даже знакомым? Тестовый сервер, понятно. Но потом ведь все-равно себе перенесешь.

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

Возможно, посоветуете, что почитать на эту тему.

Умные, щедрые и отзывчивые люди. Спасибо вам заранее))
  • Вопрос задан
  • 2770 просмотров
Решения вопроса 10
Во первых бекапы. Поломал - зафиксировали, отправили заяву в ментовку и восстановились из бекапа.
От закладок поможет наличие либо знаний, либо второго человека, который будет работать в комманде.
Ну и самое главное - хорошие отношения с работниками и не наё... с зарплатой, обещал - плати.
Ответ написан
thewind
@thewind
php программист, front / backend developer
Git + gitflow + code review
Любые странные куски обсуждаются
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
Он запрятал кусок кода, что если на сайт входит юзер с ником xxx, то удалить всю базу данных пользователей.

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

Что делать?

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

Как доверять сердце своего проекта незнакомых людям?

Так же, как вы доверяете зубному.

Особенно интересно, как этот вопрос решается на крупных сайтах.

На крупных сайтах это решается за счет контроля доступа и штата программистов и сисдаминов, которые поддерживают систему 365/24/7

Может ли там кто-то взять и завалить сайт в одиночку?

Да, безусловно. Но смысла в этом нет.

В общем, очень интересная тема, в которой ничего не представляю.

Программисты - люди далеко не глупые, как правило. Действия, что вы привели в пример возможны, но только в случае крайнего недоверия программиста-новичка к вам как заказчику.
Ответ написан
@xfg
Удалить может и пользователь используя уязвимость. Вообще в этом мире существуют бекапы, а так неплохо бы код ревью делать. Никакие изменения не мержатся пока их не подтвердят два других разработчика. Не для того чтобы обезопаситься, а чтобы спагетти-код не проходил. Это в интересах разработчиков. Им же возможно в будущем придется разбираться в этой лапше. Поэтому проще сразу отклонить.

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

Если у вас всё делает один человек, а вы только создаете видимость работы, то конечно он вас кинет если будет прибыль. Сколько уже видел таких ламерских проектов. Пациент нашел раба. Сам ничего не может. Жмет кнопки в админке. Считает, что работает за семерых. Раб везет телегу до поры до времени. Упс, а у пациента даже бекапов нет. Ибо идиот. Прикольно за этим наблюдать.
Ответ написан
CityCat4
@CityCat4 Куратор тега Информационная безопасность
Если я чешу в затылке - не беда!
Решается комплексом из технических и юридических мер.
Технически - бэкапы, разные, разными средствами, никому недоступные.
Юридически - изучить гл. 70 ГК РФ "Авторское право" (там много не относящегося к ПО, правда), дать изучить бэкендеру. Изучить УК РФ, ст. 146 и ст. 272 - и дать изучить бэкендеру (особенно ст. 272). Правильно составить договор - там тонкостей до... фига :)
Ответ написан
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
Особенно интересно, как этот вопрос решается на крупных сайтах. Может ли там кто-то взять и завалить сайт в одиночку? В общем, очень интересная тема, в которой ничего не представляю.
Не буду многословен в этот раз, расскажу Вам вкратце, как это реализовано у нас:
0. Тим лид/Ведущий разработчик/Руководитель отдела разработчиков или иной ответственный, проводящий анализ кода (Code review)
1. Договор, в котором чёткое написано, что за причинение умышленного ущерба работодателю/проекту - штраф (очень много тыс. зеленых рублей)
*я ещё хотел вписать в договор пункт, на подобии "за систематическое нарушение Code convention (соглашения по написанию кода) - отрубать по одному пальцу", но юрист не одобрил...

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

Подберите хорошего (как специалиста) и преданного своему делу, адекватного руководителя проекта/разработчиков, сочетание таких факторов как "здоровая атмосфера" на работе + договор с пунктом "за причинение умышленного ущерба проекту - ответственность вплоть до уголовной" + соблюдение обязательств перед разработчиками с Вашей стороны - разительно сокращает риск различных негативных поступков со стороны разработчиков (впрочем, как и любых других людей).

На 100% застраховаться, разумеется не получиться, но любой вменяемый разработчик, должен понимать, что за проектом следят/смотрят, и "откуда растут ноги" у такого явления как "убили базу и положили сайт" - при желании можно быстро найти, проанализировав некоторый срез активности... Иногда неплохо им об этом напоминать.
Ответ написан
vikkyshostak
@vikkyshostak
< This head full of dreams.
Если убрать за скобки советы, в стиле «не обманывай — не обманутым будешь», и прочие «мотивационные штуки на рабочих местах», то такие вопросы легко решаются (или не возникают вовсе) введением код-ревью в pre-commit-to-master ветке Git и полным покрытием тестами.

Даже строгий договор и прочие юридические штуки — не могут обезопасить проект от такого произвола. Нет, с точки зрения «кто виноват и сколько он за это заплатит» — всё хорошо.. но оставшейся команде или новым разработчикам — от этого не холодно не жарко — им же всё исправлять. Это я уже из своего опыта разгребания подобного кейса говорю :)

Работает это довольно просто: в продакшен проект попадает только после обсуждения каждой функции в спец. ветке на гите и только после прохождения всех тестов. Любая сомнительная функциональность — просто не пройдёт такой контроль и будет вызывать подозрения. Например, в вашем кейсе, про удаление БД при заходе с определённого пользователя — это будет сразу видно. Как в коде функции (на код-ревью), так и в тестах.

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

Да, это дольше, но такой подход плюс продвинутая система бэкапирования БД — даёт хоть какие-то гарантии.

«Большой брат» — это благо для компании, если вы не уверены в своих сотрудниках.
Ответ написан
swanrnd
@swanrnd
Издатель HTML5 игр
Разбираться либо искать того, кто контролирует.
PHP это все не ограничивается
Триггер на базу данных можно интересно использовать.
Но на мой взгляд самое изящное, это "случайно" допустить SQl инъекцию в каком-то редко используемом скрипте.

Можно еще договор, но не спасет, если нет специалистов по программированию и юристов
Ответ написан
KorniloFF
@KorniloFF
Работаю по font-end / JS
Можно синхронизировать 2-3 сервера, чтобы они периодически давали друг другу запросы. Как только статус ответа будет отличен от 200 - сервер автоматом блокировать и подключать следующий по цепочке. Думаю, на крупных проектах примерно так и работает. Плюс своя группа быстрого реагирования для поиска багов.
Ответ написан
@lotse8
Чтобы себя обезопасить, нужно делать все официально.
Договор, где все четко прописано. Права на продукт, всякие случаи тоже.
Платить исполнителям согласно договора через банковский перевод, а не из рук в руки без расписки.
Соответственно и налоги тоже надо своевременно уплачивать.
Если очень страшно, то нужно научиться самому администрировать сайт продакшн - вносить изменения в БД, скрипты, делать бэкапы и прочие дела по хостингу.
Но при всем при этом от закладок Вы застрахованы не будете, зато в случае срабатывания закладок сможете предъявить официальные претензии разработчикам.
Если же у Вас все на честном (или не очень честном) слове держится, то никакой защиты от закладок у Вас не будет.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Recosh
@Recosh
Программист студент
Я как программер по поводу закладок вообще не представляю как искать. Ибо например можно такого в минифированные либы понакидать, да ещё и с зависимостями, что закладку в виде простенького eval удалишь, и весь сайт будет в ошибках... Или можно оставить просто не экранированную переменную и через нее получать доступ к базе... Сам пока работаю в одиночке, но команда дело времени.
Рассчитываю на систему контроля версий, бекапы.

Но от слива информации пока не знаю как защищаться...
Ответ написан
kumaxim
@kumaxim
Web-программист
Тебе нужно сделать так, чтобы у твоего человека не было мотивации тебя подставить.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы