Ограничивать ли пользователей по ресурсам?

Сколько я занимаюсь ИТ - столько я слышу от админов "больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу". И ровно столько же у меня возникает вопрос: какое ваше дело?
Давайте забудем, что мы ИТ-шники и управляем клевыми СХД, фермами серверов, поточвыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.

1. Чем занимается ваша компания?

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

2. Кто производит деньги?

А их производят те самые "тупые юзвери", которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.

3. При помощи чего они производят деньги?

Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы - сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.

4. Кому принадлежит ИТ инфраструктура и ресурсы?

Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы "своими". Даже немного, и начинают относиться к ним соответственным образом.

Правильный ответ: они принадлежат компании (владельцу компании) и должны исполнять свою задачу по генерации денег.

5. И теперь - кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?

Как мне кажется, это абсолютно точно не должен быть ИТ админ. Просто потому что он понятия не имеет о том, как эти ресурсы приносят деньги.
Потребление ресурсов должно быть неограниченным со стороны ИТ, с практически нулевым весом ИТ в принятии решения о выделении ресурсов на ИТ инфраструктуре. Кроме разве что моментов, когда внезапный рост потребления может положить всю инфраструктуру целиком.

Необходима система внутреннего биллинга, которая вместо ограничения потребления попросту присылает в конце месяца счет начальнику отдела и фин. директору о том, кто сколько и каких ресурсов потребил. В рублях. Просто потому что именно эти два человека понимают какую доли прибыли генерирует данный сотрудник и сколько ему надо ресурсов для генерации этой прибыли.

Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.

1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.

Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям - но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.

2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.

Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки - и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.

3. У нас в ИТ ограниченный бюджет и мы не можем позволить им есть ресурсов сколько они хотят.

Позвольте, но это классический пример "административная проблема техническими средствами не решается". Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели - это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.
Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем "теневого ИТ".

И да, это все я рассказываю с 2014 года. "Департамент ИТ против частного облака"

Какой же язык программирования самый облачный?

Данный пост навеян обсуждением в Фейсбуке, начавшимся с "на JS и PHP написаны все говнооблака спорить не буду. А что потом? Так вот, за F# будущее".
В процессе обсуждения была высказана интересная мысль, даже смелая: "Облако - это новая вычислительная среда. Она устроена действительно по-иному нежели привычные нам персоналки".
И вот в чем вся соль: оба этих утверждения неверны.

Облако - это прежде всего самообслуживание и биллинг, это непременные атрибуты XaaS. Внизу облачный сервис состоит из множества маленьких сервисов, подсервисов и подсистем, каждая из которых может быть написана на любом языке или даже смеси языков. На некоторых языках программирования удобнее писать определенный вид сервисов. И то, если у вас есть команда разработчиков, хорошо владеющих данным языком и всей обвязкой к нему в виде библиотек и импортируемых модулей.
Я лично назвал бы только два с половиной языка, на которых можно написать полный стек облачного сервиса - это C, C++ и Java. Во всех остальных случаях придется использовать несколько языков. Но удивительное дело, ни один из них не нов и ни разу не облачен.

Вернемся ко второму утверждению о принципиально новом устройстве облачной среды с точки зрения программирования.
Как только мы отбрасываем биллинг и самообслуживание в PaaS, то оказываемся в совершенно традиционной среде, существовавшей задолго до облаков, хотя может быть и не столько популярной. И называется она Grid. Ничего нового облака нам снова не принесли, кроме значительной популяризации архитектуры грида. Возьми любое популярное PaaS облако, как например AWS или Azure - это не более чем набор очень больших гридов на каждый сервис и API к ним. API, кстати, тоже совсем не облачное изобретение.
Впрочем, есть пожалуй одна из архитектурных концепций, зародившихся примерно одновременно с облаками. Хотя я бы поставил ее как основу облаков, а не их следствие. Архитектура, построенная по принципу Design To Fail, или по-русски рассчитанная на отказ. Классическая привычная нам архитектура монолитных систем высокой доступности не может масштабироваться, и по сути ограничена сверху размером хоста. Для Scale-Out, неограниченно масштабируемой горизонтально системы, требуется не высокая доступность, а способность переживать отказ части узлов грида с минимальными последствиями для жизни всей системы.

Итого:
1. Нет никаких "облачных" языков, есть лишь универсальные и специализированные. Облако может быть построено на любом универсальном или любом миксе специализированных языков программирования.
2. Облака ничем не отличаются по архитектуре от дооблачных сервисов, несмотря на значительное развитие и появление новых сервисов в облачную эпоху.

Угроза от инсайдера в облачной инфраструктуре

По мере движения к 100% виртуализации и автоматизации все увеличивается влияние администратора платформы виртуализации на всю инфраструктуру. Вплоть до того, всю работу одного из Top3 американских банков можно парализовать одним скриптом, запущенным с достаточными привилегиями.
Все чаще случаи, когда обиженный уволенный администратор заходит по вайфаю из МакДональдса и кладет всю инфраструктуру.
Нашумевшая история с CodeSpaces - преступники требовали денег, а не получив, удалили все данные и бэкапы.

При этом наблюдается ситуация, когда быстрее трат на информационную безопасность растут только финансовые потери от инцидентов.

В итоге безусловно будет усиливаться контроль и прессинг в сторону привилегированных пользователей и администраторов. Но что меня удивило - даже от самых профи, сидевших на сцене, я не слышал одного. Я не слышал даже подтверждения наличия чисто административной проблемы с инсайдерами.
Инсайдеров можно разделить на несколько типов:
1) Сделают гадость и продадут данные вне зависимости ни от чего
2) Могут сделать, а могут и не делать
3) Не будут делать гадость, даже если с ними обойдутся очень нехорошо.

Третий тип проблемой очевидно не является с точки зрения безопасности. С первым стоит проблема своевременного обнаружения и контроля, в том числе отделом кадров. 
Остается второй тип, способный склониться как в одну, так и в другую стороны, причем по моему глубокому убеждению значительное количество, или даже просто подавляющее большинство.
В случае с преступлением полиция обычно рассматривает мотив преступления наряду с возможностью его совершения. И если возможность у нас по определению 100%, говорим ведь об администраторах с наивысшим уровнем доступа, то вот мотивом не интересуется никто. Вопрос стоит: как ограничить права, как не дать совершить нежелательные действия. Иными словами, проблема административная решается техническими методами.

В конечном итоге у меня сформулировалась пара тезисов по облачной безопасности:
1) Угроза от инсайдера всерьез начинается, когда сотрудников рассматривают как инсайдеров и угрозу, а не помощников. Когда их рассматривают в качестве легко заменяемых ресурсов, а не людей. 
2) Лояльность сотрудника к компании начинается с лояльности компании к сотруднику.

Выступающие не смогли ответить на вопрос: какой процент инцидентов с инсайдерами был вызван плохим отношением менеджмента к “инсайдерам”? Подразделения по ИБ НЕ занимаются этим вопросом.

Если не решены административные и организационные проблемы, то технические средства не только не будут работать, но зачастую будут только ухудшать безопасность.
 

По мотивам сессии SEC2296.

SLA? Это ли нужно для частных облаков?

Часто слышу аббревиатуру SLA. Причем в контексте "у нас есть SLA, а значит есть облако".

Нет, мои дорогие. В большинстве случаев (90%+) то, что у вас есть - это даже не SLA.
Давайте разберемся с терминологией:
SLO (Service Level Objective) - заданный уровень качества сервиса. Зачастую выражается в девятках, иногда в простоях в год (равнозначно). Что же такое девятки и их количество? Пять девяток, известные как "офигеть как круто", означают, что сервис доступен 99,999% времени (допускается простой пять с половиной минут в год).
Но в большинстве случаев путают SLA и SLO. В чем же принципиальная разница между ними?
SLA (Service Level Agreement) = SLO + штрафные санкции. В случае отсутствия четко прописанных штрафных санкций не может идти речи ни о как каком SLA. Это не более, чем SLO с обещанием "честное слово, постараемся".

С другой стороны наблюдается проблема неспособности бизнес-подразделений сформулировать хоть сколько-нибудь внятные цифры SLO. Архитектор приходит к бизнесу и спрашивает - а сколько для компании будет стоить потеря данных за последний час, и сколько будет стоить один час простоя сервиса? И бизнес потерялся. Их никогда не спрашивали об этом, никто никогда даже не задумывался.
Зачем это спрашивает архитектор? Затем, что при вопросе какие вы хотите увидеть в SLO показатели RPO (Recovery Point Objective) и RTO (Recovery Time Objective), следует ответ - конечно же ноль. Архитектор проектирует систему с простоем, стремящимся к нулю, и нулевой потерей данных. У бизнес-подразделения глаза лезут на лоб от стоимости.

Мало назначить RPO(RTO), надо обосновать почему именно такая цифра должна стоять. Исполнение заданных в SLO цифр несет определенные расходы на внедрение и поддержку, и это тоже нужно учитывать. Лишь после можно говорить что-то о штрафных санкциях и SLA.
В большинстве случаев же штрафные санкции за неисполнение будут заключаться в "генеральный намылил часть тела CIO прямо на собрании директоров". За что ему намылили? За то, что "система из говна и палок не шмагла..."

Нет, ну серьезно, какие тут SLA и облака, если из говна и палок?