Мы внедряем услугу, которая требует доступ к трем дискам, которые находятся на разных серверах. Я смонтировал диски (2 на файловых серверах Windows, cifs; 1 на другом сервере Linux, nfs), и теперь скрипты работают нормально.
Мой менеджер не очень доволен «постоянным монтированием» и считает это угрозой безопасности: если какой-либо сценарий на сервере будет скомпрометирован, можно будет получить доступ к подключенным дискам. Он предлагает, чтобы каждый сценарий которому нужны диски, горы диски в начале скрипта и монтирует их в конце сценария.
Мне не очень нравится эта идея, но я не могу его убедить. Некоторые аргументы, которые я пробовал:
Может ли кто-нибудь сказать мне, прав ли я в том, что каждый раз настороженно относился к этому креплению / монтированию, или если я ошибаюсь и это действительно правильный путь, а точнее: почему?
Автоматическое монтирование сетевых ресурсов означает хранение учетных данных в файле где-нибудь в mount может их прочитать (через credentials=filename mount в случае файловых систем cifs) - это не обязательно проблема, но может быть проблемой безопасности, помимо эксплойта, дающего кому-либо доступ к скрипту. Хранение учетных данных в таких файлах более безопасно, чем сохранение их непосредственно в сценарии, потому что в этом случае они не будут отображаться в командной строке, когда пользователи будут искать список задач с помощью ps или подобное, но жизненно важно убедиться, что только сценарий может читать файл. Вы обеспокоены тем, что пользователи, которые скомпрометируют сервер, ничем не отличаются в этой ситуации - если они скомпрометируют сервер во время его работы, они все равно потенциально получат доступ к общим ресурсам.
Стоимость подключения и размонтирования общих ресурсов не должна быть значительной - максимум несколько секунд (если так), если вы не разговариваете с общими ресурсами через очень медленное соединение с высокой задержкой, и может быть предпочтительнее с точки зрения безопасности, потому что вы не являетесь сохранение общего ресурса подключенным (потенциально таким образом, чтобы он мог быть доступен для чтения другим пользователям, имеющим доступ), когда он не нужен, и другой конец сможет регистрировать, когда ваши скрипты аутентифицируются и отключаются (поэтому, если на другом конце обнаружена проблема в конце, легче отследить, что могло иметь доступ в то время, когда проблема могла возникнуть).
Сохранение общих ресурсов смонтированными, несмотря на перекрывающиеся выполнения сценариев, может быть выполнено путем удаления файла со случайным (или с достаточной вероятностью дублирования другим вызовом сценария) именем в некотором месте (скажем, в каталоге под /var/run) и удалив этот файл после завершения фактического задания сценария - чем в самом конце убедитесь, что в этом каталоге нет других файлов перед запуском umount. Другой метод - разрешить несколько подключений к одному и тому же общему ресурсу, предоставив каждому скрипту свою собственную точку монтирования - таким образом, каждый скрипт будет иметь свой собственный общий ресурс и не будет мешать другим, и вы также можете предоставить каждому скрипту свои собственные учетные данные для аутентификации, чтобы у вас есть возможность более детально управлять разрешениями на другой стороне (например, для некоторых скриптов требуется доступ для чтения и записи, а для некоторых - только для чтения).
Извини но ты не право.
С уважением