Pull to refresh
9
0

Пользователь

Send message
Решение HP о предоставлении прошивок только в течение гарантийного срока просто убийственное.

Понятно, что это маркетинговый ход, нацеленный на периодическое обновление серверного парка продукцией компании HPE, но вещь неприятная, соглашусь. Но всегда есть гугл под рукой — в свободном доступе SPP есть, в том числе на DL20 Gen9.
Если отбросить момент с доступностью firmware, то могу с Вами не согласиться — поддержка у HPE работает. Периодические даже на Gen8 выходят обновления.

А вот что касается оперативной памяти — DL20 Gen9 поддерживает только UDIMM (небуферизированную память) (пруф на 65 странице мануала). Указанный Вами парт-номер свидетельствует о том, что память все же RDIMM ECC.
Новые каталоги и подкаталоги, на которые определяются права доступа отличные от родительского каталога, содеются и настраиваются администратором, а дальше специально обученные девочки добавляют пользователей в группы, на которые у них есть права, по заявке. Я учувствую в этом “празднике жизни” только на начальном этапе, что там дальше происходит мне не интересно. Если возникнет необходимость беспрепятственно можно получить состав группы, а по имени ясно куда применяется.
Full Control им не нужен, права должен менять кто-то из администраторов. Если бы у администратора голова не болела за файловый сервер, то и обсуждения этого не было бы.
Техподдержку можно включить в группу …_R или …_W базового уровня. А права локального администратора для них избыточны. С другой стороны администраторы сервера должны иметь возможность управлять каталогами этого сервера.
Права для владельца вырезаются на уровне родительского каталога – делается это для того чтоб где-то “не выстрелил“ доступ данным фактическому владельцу мимо разрешений на каталог куда был перемещен объект.
Сурово конечно… но ведь работает! У нас в похожем случае стали тащить все подряд — так на “всякий случай” да “про запас”. Места не прибавилось, но хотя бы с владельцами определились.
Спасибо за замечания.
  • У меня лес доменов и область действия групп выбирается по необходимости – иногда необходимо организовать доступ так чтоб туда случайно не добавили учетную запись из другого домена.
  • У меня несколько файловых серверов и мне удобно по имени группы определять где физически находится каталог. DFS – штука хорошая, но везде применяемая.
  • Именно по этому я не приветствую “конские” имена каталогов и разграничение прав доступа ниже 3 ну максимум 5 уровня.
  • У меня на 2012 сервере ABE скрывает имена файлов если нет прав на чтение или запись.
  • Абсолютно согласен.
За аббревиатурой невидно деталей. Ко мне не раз обращались вопросом “как лучше сделать” или “а как у тебя сделано”. Здесь для широкого круга специалистов описано как я делаю на своих серверах. Надеюсь, это принесет определенную пользу.
Не вижу смысла делать еще одну группу подменяющую локальных администраторов. Access Based Enumeration использую по умолчанию – вошло уже в привычку. Я описал ситуацию где есть сотрудники которые должны писать в подкаталог “2016” без прав на запись в “Public” или “Новости”. У меня несколько файловых серверов и случается, что необходимо по имени группы определить где физически находится каталог. Это экономит время – нет необходимости лезть в АД смотреть описание группы.
Не представляю сотрудника с достаточно широкими правами, в тоже время настолько бесполезного, что его можно уволить в один день без ущерба для бизнеса.
Для удобства обработки человеком. Компьютерам все равно, а мне удобнее. И когда в оушке будет больше 2000 объектов оснастка начнет выдавать предупреждения.
По сути, мы преследуем одни и те же цели.
Пример из жизни: сервер на 12 TB, ежеминутно что-то удаляется… я не хочу быть промежуточным звеном, запускающим скрипт или делающим выгрузки для ответственных сотрудников. Аудит ФС включен и используется для расследования фактов удаления данных.
Теневые копии для интенсивно используемого файлового сервера и последующий анализ журналов – вариант интересный, но трудозатраты по анализу логов могут потребовать отдельного, хотя бы, специально “натасканного” сотрудника.
Ну мы же не параноики… Основной посыл в том, как заблаговременно организовать доступы и потом получить более комфортные условия для контроля. Но никогда не поздно начать.
Мне жаль, что у Вас есть такой печальный опыт, но поводы и причины для скандала и увольнения могут быть самые разные…
Возможность оперативно оценить риски ИБ не является “перекрытием кислорода”. Проанализировав доступы можно будет принять правильные решения, например, что необходимо предоставить приемнику для обеспечения непрерывности бизнес-процессов.
Пункта “0” не существует — сотрудник подал заявление и у него есть еще две недели, учетная запись блокируется только после увольнения.
Если компания невелика, то можно поставить напольную модель и под столом сисадмина.

Information

Rating
Does not participate
Works in
Registered
Activity