Наш исходный код - наш самый ценный актив. Я бы хотел его иметь:
Есть рекомендации по стратегиям? Или я параноик?
Защита вещей от действий ваших людей - это, к сожалению, больше человеческая проблема, чем технология, поэтому я оставлю это другим, чтобы ответить (люди - не моя сила - машины: да, кошки: иногда, люди: нет!).
Если вы отправляете свой код в любую внешнюю службу, вы должны либо убедиться, что он надежно зашифрован перед отправкой, либо у вас есть в полной мере проверили внешнюю службу, желательно обе. Запуск собственных серверов резервного копирования будет безопаснее (у вас более прямой контроль), но более сложным (вам придется все делать самостоятельно). Поскольку ваши серверы резервного копирования, вероятно, будут работать в пространстве colo, которое у вас нет физического контроля, вы можете захотеть установить данные в зашифрованных файловых системах. которые не монтируются автоматически при загрузке (требуется ручное вмешательство для отправки ключа (ов), если серверы нуждаются в перезапуске) - наличие ключей на сервере, чтобы он мог автоматически монтировать зашифрованные тома, все равно, что иметь дорогой сейф с комбинацией, написанной на заметка поблизости.
В любом случае у вас должны быть автономные резервные копии, а также онлайн-резервные копии, то есть диски / ленты вне офиса и не подключенные. Таким образом, если вы полностью взломаны и все ваши основные серверы, локальные резервные копии и размещенные онлайн-резервные копии разрушены, у вас все равно должны быть автономные резервные копии, к которым можно откатиться.
Один из способов смягчить проблему взлома хакером ваших основных серверов и их использования для взлома ваших резервных серверов (что произошло с относительно высокопрофильной веб-службой несколько месяцев назад). Я предлагаю иметь промежуточную службу, которая будет работать как в реальном времени, так и в резервном. серверы подключаются к. Таким образом, вы не сможете организовать доступ друг к другу ни живым, ни резервным серверами, а промежуточному серверу не нужно будет входить в систему ни в реальном времени, ни в резервном. Активные сайты будут подключаться к промежуточному серверу, чтобы передать самые свежие данные, и через некоторое время после входа в систему резервные серверы будут загружать их себе. Это не отменяет рекомендации о наличии автономных резервных копий вне офиса, хотя снижает вероятность того, что вам придется использовать их в гневе.
Еще один дополнительный вариант для размещения ваших внешних резервных копий: если вы используете очень хорошие отношения с другим местным неконкурентным бизнесом, возможно, вы могли бы разместить резервные копии друг друга. Вы все равно можете зашифровать свои резервные копии на случай истинной паранойи (не в случае, если другой бизнес пойдет не так, хотя это может случиться, а для того, чтобы скрыть возможность того, что они будут взломаны или ограблены сами).
И еще один момент, которым слишком часто пренебрегают: убедитесь, что у вас есть процедура для тестирования резервных копий. Вы же не хотите, чтобы они перестали работать по какой-то причине несколько недель назад в тот день, когда вам нужно что-то от них восстановить. Существует множество способов проверить ваши резервные копии, лучший из которых зависит от характера и размера данных, которые вы храните, и формата, в котором они хранятся. Например, у меня есть копия моего почтового сервера, работающего в ВМ, что думает это активный сервер, но его не видно из внешнего мира. Три раза в неделю сценарий останавливает его, восстанавливает для него самую последнюю резервную копию и перезапускает ее, при этом все ошибки отправляются мне по почте. Затем, как часть моего обычного домашнего хозяйства, я вхожу в эту резервную виртуальную машину, чтобы проверить, все ли в порядке (она работает, последние изменения присутствуют, случайная выборка старых данных тоже выглядит нормально ...). Вы все равно должны иногда вручную тестировать резервные копии, но автоматические тесты иногда являются находкой - они могут выявить незначительную проблему, прежде чем она станет серьезной.
Трудно быть слишком параноик при присмотре за исходным кодом. Это ваш основной актив, без него ваш бизнес может ничего не стоить, поэтому вам нужно очень тщательно защищать его от внешних злонамеренных сил (включая силы природы!).
Нет абсолютно никакой разницы между вашим исходным кодом и любыми другими файлами, которые вы хотите сохранить конфиденциальными (например, финансовые). Человеческая сторона - это то, с чем вам придется иметь дело по своему усмотрению. Безопасность и целостность файлов можно контролировать несколькими способами. Я предпочитаю делать собственные резервные копии на ленту. Эти ленты хранятся за пределами предприятия, поэтому в случае бедствия (например, сгорание здания - снова!) Данные будут потеряны не более чем за один день.
Обдумывая использование «облака», просто имейте в виду, что оно называется так потому, что здесь нет резких границ или определений. Проще говоря, вы не можете знать, где находятся ваши данные в любой момент времени и кто имеет к ним доступ. Если вы так сильно чувствуете, что ваши данные нуждаются в защите, тогда вы должны иметь прямой контроль над ними.
Нет, вы не параноик. Мне приходит в голову пара вещей
Зашифрованы ли жесткие диски и USB-ключи ноутбуков ваших разработчиков?
Резервное копирование в «облако» - нормально. Вам следует подумать о резервном копировании и хранении резервной копии за пределами площадки.
\\ Грег
Просто идеи:
Прежде всего, используйте систему контроля версий. По крайней мере, таким образом сохраняется история файлов. Если что-то случится с файлом, вы всегда можете отменить изменения.
Во-вторых, я могу рассмотреть возможность использования DVCS, например мерзавец или базар. Использование DVCS позволяет создать рабочий процесс, в котором разработчики могут разветвлять весь репозиторий. Они могут извлекать файлы, фиксировать файлы, тегировать, объединять и т. Д. В своей собственной ветке, независимо от всех остальных. Затем сохраните репозиторий главной магистрали на защищенном сервере, доступ к которому имеет только привратник. Разработчики могут объединять изменения из ствола, но лишь немногие избранные имеют доступ для фиксации в стволе. Привратник также может быть автоматизированной службой, такой как PQM, или другим инструментом управления исправлениями.
В-третьих, резервное копирование может быть непростой задачей. Такие вещи, как "Вы хотите, чтобы физические резервные копии хранили подальше?" "Вы хотите зеркальный сервер?" "Насколько велико ваше хранилище?" "Какой уровень безопасности мне нужен?" Я не думаю, что могу ответить за вас на некоторые из этих вопросов, но вы должны принять их во внимание при разработке плана резервного копирования.
И НЕТ, вы не параноик ... это то, с чем должна иметь дело каждая софтверная компания ... это ваш IP, вам нужно его защитить.
В трудовом договоре, подписанном при приеме на работу, должно быть очень четкое заявление, в котором говорится, что все является собственностью компании, и что технология / код не могут использоваться вне компании и т. Д. Вы не можете помешать им нарушить это, но если это случается, вы можете подать в суд и выиграть ...
Еще одна вещь, которую нужно сделать, - убедиться, что сотрудникам нравится их работа, и тем самым создать лояльность по отношению к компании, что снижает риск их желания использовать свой доступ к коду.
Делаем бэкапы на съемные диски. У нас есть 3 сменных диска для резервного копирования: один подключается к компьютеру, выполняя ежедневное резервное копирование, один заблокирован в пожарном шкафу в офисе, а третий находится дома с системным администратором. 3 диска вращаются. Это гарантирует, что у нас всегда будет одна резервная копия вне офиса на случай пожара.
Первая - это политическая / социальная проблема (если вы не собираетесь обыскивать их приходящих и выходящих из здания, в дополнение к предотвращению большей части исходящего трафика, любая электронная блокировка является ложной защитой витрины).
Во-вторых, зашифруйте файлы локально (на своей стороне), а затем отправьте зашифрованные копии своему провайдеру хранилища. Мне нравится идея Jungle Disk, где вы создаете и храните свою учетную запись Amazon S3, а затем используете программное обеспечение Jungle Disk для копирования файлов на Amazon. У вас будет криптоключ. Для корпоративного сайта вы можете самостоятельно продублировать функциональность Jungle Disk и получить полный контроль.