Для некоторого контекста я имею дело с устройством Synology RackStation, на котором работает почти полностью обновленная версия DSM. Специфику этого полезно знать, если вы знакомы с Synology, но это не обязательно, потому что это просто настроенный дистрибутив Linux.

Прежде всего, они каким-то образом заблокировали SSH, чтобы его могли использовать только люди, входящие в группу «администраторы». Я не уверен, как именно — я подозревал PAM, но когда я отключил его и попытался использовать предложение Match в sshd_config, это не изменило поведения. Когда я запускаю ssh с флагами -vvv, кажется, что аутентификация прошла успешно, а затем соединение разрывается после этого.

Итак, мой первый вопрос — как отследить, где и почему обрывается соединение.

Независимо от этого, у нас возникла проблема с синхронизацией с Amazon S3, и нам нужно было привлечь Synology для устранения неполадок и отладки. Чтобы получить их поддержку, они часто просят удаленный доступ. В этом случае я не могу дать им это из соображений безопасности. Поэтому я подумал, что могу настроить среду chroot с привязкой ко всему, кроме данных, которые необходимо защитить.

На самом деле, это очень хорошо работало при тестировании, но очевидно, что для работы SSH, опять же, учетная запись удаленного доступа Synology должна быть частью группы administrators, и в этом случае они имеют полный доступ к пользовательскому интерфейсу, где они могут якобы предоставить себе доступ к файлам на устройстве через приложение WebUI.

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

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

0
Harv 27 Май 2020 в 07:04
Привет @MarkPlotnick, то, с чем мы столкнулись, по-видимому, является ошибкой, поэтому, вероятно, она ограничена устройством, используемым в производстве, и может не отображаться на демонстрационном устройстве, которое они нам присылают.
 – 
Harv
27 Май 2020 в 17:09

1 ответ

Если вы серьезно относитесь к защите хранимых данных, вы уже должны были подумать о том, что произойдет, если кто-то украдет ваш NAS. Единственный способ защитить ваши данные — зашифровать их на диске. Synology предоставляет для этого руководство.

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

0
meuh 27 Май 2020 в 14:45
Я это учитывал. Тот факт, что ключевой файл приходится выбирать вручную при загрузке, непозволителен. Вместо этого мы усилили физическую безопасность, чтобы было очень трудно добраться до устройства для кражи. Хотя я понимаю вашу точку зрения, и она действительно хороша.
 – 
Harv
27 Май 2020 в 17:06