Category: Инфраструктура

Домашен дейтацентър или лаборатория|HomeLab, Home Data center

Много devops, програмисти, системни и мрежови администратори изграждат свои домашни лаборатории, мини дейтацентрове, включително доста амбициозни и сериозно направени системи…

В тази статия разглеждам някои от съществените лимити, с които следва да се съобразяваме в амбициите и инвестициите си.

Тъй като е удобно и дори изглежда изгодно да натоварим домашната си лаборатория със сериозни задачи (например проекти за клиенти) – изхождайки от опита си за проектиране и изграждане на сериозна домашна лаборатория (от клас мини дейта център :), споделям лош опит, в желанието си да спестя на читателя настъпването на някоя и друга мотика по пътя. 😉

1. Не правете голяма инвестиция – в крайна сметка домашната лаборатория е за тестове и PoC (Proof of Concept), използването и за други цели рано или късно води до задънена улица и по някое време ще се наложи да отпишете инвестираното и направите нещата както трябва.
Все пак, по-долу (т. 7.) описвам добра (макар не изключителна) идея, която може да осмисли сериозното използване на домашната инфраструктура.

Така че – инвестирайте разумно и пестеливо, за да не загубите много (пари, време, нерви, недоволни клиенти и пропуснати възможности).

2. Причината да отпишете инвестицията е, че домашният дейтацентър не скалира добре – нито в посока повече оборудване, но винаги ще е зле в посока отказоустойчивост и надеждност на работата.

Винаги! Винаги!!

Дали съм достатъчно категоричен?

Винаги!!!

3. Имайте предвид, че много рядко електрическите инсталации в стандартните жилища са оразмерени добре, за да поддържат
7 x 24 x 365 дори малки товари от 1-2KW. Това не винаги се забелязва и никога не е проблем в началото, но е добре да се провери след няколко месеца работа дали предпазителите и изходните шини не греят. Следващите индикатори са черни конвективни следи над таблото, миризма на изгоряло и вой на пожарни сирени.

4. Проблемите с шума са добре известни и всеки чувал стартиращ или натоварен сървър има ясна звукова представа за тях. :). Ще добавя само, че шумът от вентилаторите на средномощен сървър, в някои сгради се чува и през нощта, включително И от съседите.
Разбира се, те не са чак такъв проблем, но помислете за отношенията си с партньора… 🙂  

5. Охлаждането – няма лесен и смислен начин да направите добро охлаждане, ако ще имате повече сървъри. Студеният въздух трябва да се движи отдолу нагоре и фронт/гръб спрямо сървърите (ако са за рак монтаж). Това, което можете да направите е да държите достатъчно ниска температурата в помещението, за да осигурите генерално температурния режим на оборудването, но тази схема консумира повече енергия и поради това е ценово неефективна.

Е, ако имате достатъчно средства може да заложите на рак със собствена климатизация, но това е инвестиция, която не си струва предвид описаното в т. 2.

6. Възможните компромиси –

– Ако просто имате нужда от домашен лаб – използвайте втора ръка мобилни работни станции – те дават доста мощност и са относително тихи (стига да не спите в едно и също помещение с тях). Предимствата им – не ви трябва UPS или KVM имате си вградени монитор, мишка и клавиатура.

– За ML (Machine Learning) – сглобете си машина с големи бавни вентилатори, не повече от един, но възможно най-мощен ускорител, например NVidia GeForce RTX 2080Ti. Пак ще шуми, но ако е в съседно помещение се търпи. Или не се търпи – зависи…

7. Направете си (или използвайте “as a service”) мониторинг – като минимум – температура на околната среда и на системите – трябва да знаете температурното им състояние и да получавате известия при надвишаване на допустимите рамки.

Разбира се мониторинга е необходим и за други цели – например: параметри на експлоатация, надеждност, сигурност, контрол на SLA.

Хубавото в тази схема е, че когато прехвърлите проектите си, където им е мястото – тогава домашната инфраструктура може да се използва за независим (или втори) мониторинг.

8. Ако правилно изберете оркестрацията на виртуализация/контейнеризация – ще можете лесно да мигрирате приложенията си към ваши ресурси в частни или публични клауд платформи. Така ще си запазите възможноста да правите бързи и евтини тестове и PoC в домашната среда, същевременно ще можете лесно да мигрирате продакшън системите на правилните платформи.

9. Спестете си проблеми със сигурността и надеждността и разделете правилно инфраструктурата за тестове и PoC от домашния си интернет, не ги смесвайте от самото начало най-добре – т.е. организирайте си файъруол (може и виртуализиран, но с много мисъл), умен суич/и.

Повтарям – от самото начало разделете едното от другото, никакъв компромис, временно решение и прочие.

Home Office – Дистанционна работа – съвети, решения, опит

Резюме

Пандемията COVID-19 стана причина за бурно преминаване към така наречения home office (домашен офис, remote office, remote working и т.н.). Много компании, особено работещи в областта на информационните технологии и BPO (Business Process Oursourcing) бяха подготвени и кризисната реакция протече гладко. Други компании потърсиха и имплементираха решения в спешен порядък, при което основен фокус бе навременното осигуряване възможността за отдалечена работа. 

Home office представлява сериозно предизвикателство, а някои подценени аспекти на сигурността създават предпоставки за бъдещи проблеми. 

Целта на документа е да дефинира обща методологична и организационна рамка за изграждане и експлоатация на инфраструктура за отдалечена работа, както и насочване вниманието на мениджмънта към правилната организация на работния процес. 

Посочени са конкретни open source технологии и решения за изграждане и поддръжка на инфраструктура за дистанционна работа, но съветите и споделените добри практики са валидни за целия спектър на възможните, включително комерсиални решения. 

Принципи
Предварителна подготовка

Възможността за отдалечена работа се свежда до решаване на следните задачи на ниво организация и IT ресурси – 

  • Технология за създаване на роли, групи и потребители
    • Управление на фирмената IT сигурност чрез правилно проектиране нивата на достъп до фирмените ресурси
    • Дефиниране на потребителските роли
    • Разпределяне на правата по роли и групи потребители
  • Процес за управление на автентикация и оторизация на потребителите
  • Осигуряване на достъп до чрез VPN технология до фирмените ресурси
  • Контролиране на достъпа
  • Наблюдение, детекция на подозрително поведение, управление на инциденти свързани със сигурността

Доколкото във фирмите с развита IT инфраструктура, изброените проблеми и задачи са решени на локално ниво (т.е. вътре във формения офис), то накратко ще опишем технологично решение за отдалечена работа за малки фирми, не разполагащи със съответната инфраструктура, а след това ще се фокусираме върху общите предизвикателства и добри практики, гарантиращи сигурност и ефективност на отдалечената работа.  

Организация и управление на работния процес

За успешната отдалечена работа е необходимо да:

  • Организационни решения
    • Организирате управление на отдалечения достъп със съответните потребителски имена, пароли и сертификати за криптиране на комуникацията
    • Предварително определена и форсирана стратегия за управление на отдалечения достъп до фирмените ресурси

 

  •  
  • Технологични решения
    • Разполагате с механизъм потребителите самостоятелно да възстановяват забравени пароли
    • Разполагате с написана и добре структурирана помощна информация и екип в състояние да обучи потребителите и да ги поддържа в процеса на работа
    • Предварително конфигурирана и тествана в офиса свързаност към фирмения VPN сървър, за да се избегне ситуация за решаване на проблеми в момент, когато потребителите преминат към отдалечена работа от домовете си
    • Предварително инсталирани антивирусни програми
    • Предварително инсталирани системи за Host based Intrusion Detection, защитаващи критични системни файлове и директории
    • Предварително организирана система за събиране, анализ и реакция при критични събития 

 

Сигурност

Въпреки, че сигурността е част от работния процес, отделяме специално внимание на темата, защото инкубационният период на проблемите породени от бързо и недостатъчно добре планирано преминаване към режим на отдалечена работа е дълъг и това е предпоставка за сериозно компрометиране на фирмената и в частност информационна сигурност.

 

Технологии и решения с отворен код
Управление на потребители

Може да се използва LDAP или Active directory за управление на потребителски роли и групи. Извън екосистемата на Майкрософт решенията, може да се използва open source Samba Server като файлов, принт и сървър за управление на потребители в уиндоус или уеб базирана среда. 

Възможни open source решения –

VPN концентратор / сървър

Съществуват няколко широко използвани технологии, например – IPSEC или OpenVPN. Доколкото IPSEC се поддържа без инсталация на допълнителни клиенти в Windows, той изглежда естествена технологичен избор за уиндоус среда.

Лично аз препоръчвам като оптимален вариант OpenVPN, заради по-голямата гъвкавост и универсалност. Повече аргументация можете да намерите в статията тук: OpenVPN.

Ако организацията не разполага с наличен VPN концентратор, включително комерсиални решения от различни доставчици на мрежoв хардуер, като Cisco, Juniper, Fortinet, HP, Aruba, Ubiquiti, Mikrotik и много други, можете да изградите VPN решение от висок клас, базирано на софтуер с отворен код PfSense – представлява Firewall, VPN Concentrator, Intrusion Detection System, Intrusion Prevention System от най-висок клас. 

Решения за комуникация на служителите

Комуникацията между служителите (също и с клиентите) е интегриран елемент от организацията на отдалечената работа. Тук фокусът е към приложенията за онлайн съобщения – chat, а не към мейл – утвърдено, но според някои – остаряло решение за бизнес комуникация.

Обикновено фирмите разполагат с де факто механизъм, който може да е общо фирмено решение или изборът на комуникационна технология да е оставен в ръцете на обикновените потребители и в рамките на отдели и работни групи. 

Макар комерсиалните решения да имат някои преимущества, няма някакви съществени разлики, спрямо решенията с отворен код. Всъщност основна причина да използвате комерсиални решения е съвместимост с клиенти, които са инвестирали в тези технологии, но дори това не е особено огрничаващ фактор.  

Популярни средства са:

Групуеър решение за споделена работа

NextCloud е групуеър (groupware) платформа с отворен код, функционално подобна на Dropbox или Google Drive. Позволява изграждане на независима и безплатна платформа за споделяне на файлове, календар, контакти и съвместна работа върху файлове на ниво организация или по-малка работна група.

Към НексКлауд може да се интегрират уеб базирани офис приложения, например Only Office, което дава възможност за уеб базирана съвместна работа с документи (подобно на Google Drive или Offie365).

Има относително добра съвместимост с MS Office – т.е. Next Cloud + Only Office отваря и визуализира на приемливо ниво документи създадени с MS Office, респективно документите създадени през Only Office са съвместими с MS Office.  

Система за управление и контрол на сигурността

Възможността за отдалечена работа предтавлява изключителен риск за сигурността на организацията. Използването на технически средства за изграждане и гарантиране на сигурността е задължително, а използването на интегрирано решение, което съчетава както събирането, анализа на информация свързана със сигурността и механизми за реакция при инцидент – е силно препоръчително. 

Нашият избор е AlienVault OSSIM – система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Повече информация в статията –  AlienVault OSSIM

 

Съвети към IT мениджъра:
  • Организацията на възможност за отдалечена работа е свързана с два компонента
    • Ефективност на работата – т.е. контрол на производителността на служителите
    • Информационна сигурност 
  • Никога не считайте, че използването на каквато и да е технология за защита, е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Експлоатация на сървъри. Част 1. Натоварване

  • Кое е оптималното натоварване на един сървър?
  • Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
  • Над какво натоварване считаме, че сървърът е претоварен?

В тази статия ще дам някои насоки и възможни отговори. IT инфраструктурата е комплекс от много взаимозависимости и няма еднозначен отговор. Освен това натоварването само по себе си не е проблем, проблем са страничните ефекти от него.

Винаги, когато планираме и експлоатираме IT инфраструктура (за целите на статията нека разглеждаме уеб сървър), следва да отчитаме TCO (Total Cost of Ownership) като параметър. Като пример за важността – в рамките на средностатистическия полезен живот на хардуера, управлението на електрическата консумация е съществена необходимост (грубо може да се приеме, че 10% от свързания оперативен разход подлежи на оптимизация).

Изключително важно е да си осигурим добра видимост към инфраструктурата, което предполага тотален (но разумен и не изкривяващ профила на натоварването) мониторинг върху работата на системите. Добрият мониторинг дава възможност за предвиждане и изследване потенциалните проблеми още преди да сме стигнали до етапа на продукция.

Нещата са кардинално различни, ако ги оценяваме в клауд инфраструктура (т.е. имаме чиста себестойност от тип „сървис като инфраструктура“) или уебсървъра работи върху „собствен“ сървър, консумиращ „собствено“ електричество и топлоотделящ в „собственото“ помещение, което отново „собствено“ охлаждаме. На тази тема ще посветя една от следващите статии.

TCO зависи от хардуера и начина, по който го експлоатираме. Най-силна и видима е зависимостта от броя и типа сървърни захранвания. Това е така, защото ефективността на захранването е най-висока, ако натоварването му е над 60% и оптимална при ~80%.

Ако сървърът е слабо натоварен, с малко памет и дискове – консумацията му е ниска и ако използва две балансиращи натоварването захранвания – то всяко от тях ще работи извън оптималния си режим.

  • В този случай е необходимо ръчно конфигуриране за работа в режим hot/cold stand-by на едно от захранванията
  • Така другото ще се натовари повече и ще работи в оптималните граници
  • По-новите сървъри поддържат автоматизирано управление на консумацията, но е необходимо да са включени в съответния режим (обикновено не е по подразбиране)

От гледна точка разходи за електричество – колкото повече натоварите сървъра – толкова по-добре, стига системата да се държи предвидимо. Друга зависимост се проявява в случаите, когато сървърът работи върху bare metal или виртуализиран хардуер. Ако е виртуализиран, хайпървайзъра ще се погрижи голямо натоварване (70%+) на сървъра да не се отрази (в някакви граници) на латентността на другите виртуализирани услуги.

Някои конкретни съвети

Насочени са основно към системни администратори и devops. Всъщност препоръчително е CIO и IT мениджърите да са наясно с материята, доколкото TCO и качеството на услугите са тяхна отговорност.

  • Някои комбинации сървърен софтуер (например Apache/PHP) предизвикват и въобще са чувствителни към латентност. Не допускайте в продукция всичко да зависи от фронтенд перманентно натоварен над, да речем, 50%, защото:
    • Няма място за реакция на инцидентни (пикови натоварвания)
    • Влияе и усложнява откриването на други свързани или несвързани проблеми
    • В крайна сметка усложнява и оскъпява експлоатацията на цялостната система
  • Планирайте и от самото начало използвайте лоудбалансър(и) и поне два фронтенда
    • Може да бъдат виртуализирани напълно или да се използва хибридна схема за оптимално TCO
    • Когато натоварването нарастне, за да си струва – тогава може да преминете към bare metal хардуер
  • В общи линии най-изгодно е инфраструктурата да е виртуализирана (контейнеризирана в частност)
  • Контролирайте (по възможност) архитектурата на приложението и качествения код на разработчиците
  • По възможност (особено, ако разработвате бизнес критични системи) избягвайте да съчетавате множество функции в един сървър (например уеб, дейтабейс, файлов и прочие)
    • Ако това не е възможно – оставете достатъчно резерв например средно натоварване на сървърен процес под 20% (за да имате резерв за абсорбиране на пикови натоварвания)
    • Не лош вариант е да управлявате прецизно натоварването в рамките на един сървър с cgroups, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:

Виртуализация –

Контейнеризация –

Съвети за избор и експлоатация на дейта център

Увод

Целта на документа е да дефинира обща методологична и организационна рамка за избор на дейта център и последващото изграждане и експлоатация на информационна инфраструктура. Документът няма претенции за всеобхватност и отразява опита на автора в:

  • Изграждане и експлоатация на дейта център бизнес
  • Избор на дейта център за различни услуги в спектъра голям бизнес – доставчик на услуги – интернет и телеком оператор

Описани са цялостният процес за подготовка, избор, изпълнение и успешна експлоатация.

Контрол на качеството

Контролът на качеството е от ключово значение за IT операциите на организацията, както въобще и за цялостната ѝ дейност. Ето защо описвам в по-големи детайли методологията за осигуряване на качество.

Контрол на качеството на монтаж на оборудване
  • Принципи
    • Изготвяне на подробен работен проект
    • Детайлно разработен план график за монтаж, тестване и пуск в експлоатация
    • Детайлно описани дейности по инсталация и монтаж
    • След доставка оборудването се подлага на функционални тестове преди окончателен монтаж
    • Оборудването се инсталира съгласно утвърдената практика – инсталация от обучен екип, притежаващ всички необходими за дейността сертификати, при пълно спазване на определената от проектанта и доставчиците технология и в координация с персонала на организацията или трети лица, който осигурява методическа подкрепа и необходимите проводи за електрически и мрежови свързаности
    • Спазване на правилата за безопасност на труда и пожарна безопасност
    • Преди въвеждането на оборудването в редовна експлоатация се извършват необходимите огледи и изпитания за удостоверяване на съответствието им с проекта и с действащите правилници и нормативни документи третиращи дадения вид дейност
    • Изработва се подробна техническа документация на направените инсталации и към нея се прилагат всички протоколи от извършени измервания, тествания и сертифициране на системите, включително с описания и снимков материал
  • Методи
    • Изработването на тестови казуси при които се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • След инсталация оборудването се включва в система за наблюдение и управление
    • Оборудването се включва в система за наблюдение на производителност, и наличност на услугата на ниво система за наблюдение и управление през мрежовата свързаност
    • Непрекъснато следене параметрите на хардуера – температура, захранващо напрежение по компоненти, състояние на вентилатори
    • Непрекъснато следене SMART параметрите на твърдите дискове и SSD, за да се реагира своевременно при излизане на параметър извън допустимите граници
    • Тестови период, в който се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • Установява се процедура за взаимодействие  за известяване на събития между отговорните страни за поддръжка на организацията и оператора на дейта центъра
    • Установява се връзка между системата за наблюдение и управление на организацията и оператора на дейта център услугата
      • Система за сигнализация при проблем
      • Система за ескалация на проблем, съгласно параметрите на договореното ниво на обслужване (SLA)
Контрол на качеството на дейности по осигуряване на мрежова свързаност

Контролът на качеството на дейностите по осигуряване на мрежова свързаност се осъществява с прилагане на следните принципи и методи:

  • Принципи
    • Детайлно разработен план график за изграждане на свързаности, тестване и пуск в експлоатация
    • Наемане на услуги от надеждни телекомуникационни оператори,  с дългогодишен опит в експлоатацията на градски и мобилни мрежи
    • Използване на надеждно и отказоустойчиво оборудване от реномирани доставчици, разполагащи с отлична сервизна база
    • Пълна документация на направените свързаности, включително с описания и където е уместно – снимков материал
  • Методи
    • След провизиране на услуга, комуникационното трасе се включва в системата за наблюдение на производителност, качество и наличност на услугата
    • Непрекъснато следене на качествените параметри и ескалация при деградация на параметър извън договореното ниво на обслужване
    • Тестови период, в който се измерва качеството на изградените свързаности и се синхронизира взаимодействието между центровете за поддръжка на организацията и телекомуникационните оператори
    • Връзка между системата за наблюдение и управление на организацията и телекомуникационни оператори
      • Автоматизирана сигнализация при проблем
      • Автоматизирана ескалация на проблем, съгласно параметрите на договореното ниво на обслужване
Предварителна подготовка

Правилно подготвеното задание е предпоставка за получаване на добре обмислена и остойностена оферта от страна на дейта център оператора. Трябва да отговорите на следните въпроси на ниво организация:

  • Как изглежда, каква е архитектурата и какви са параметрите на цялостната информационна система – на ниво дейта център и (ако има) информационни системи на огранизацията извън дейта центъра 
  • Какви SLA ангажименти следва да гарантира тази инфраструктура (например SLA към клиентите на организацията, към вътрешни за организацията потребители), за да можете да определите своите изисквания към оператора на дейта центъра и телекомуникационните оператори (ако са различни)
  • Какви са възможностите на организацията да обслужва своя SLA – налични човешки ресурси и специализирани информационни системи
  • За препоръчване е да имате количествено изражение на SLA – време, дължимо/очаквано обезщетение. Можете да използвате този SLA Calculator, за да проиграете различни варианти
  • Направете цялостна технологична оценка
    • Размер на оборудването – дълбочината на сървърите е съществен параметър
    • Вентилационен поток – фронт към гръб или странично
    • Начин за монтаж на оборудването в шкафовете
      • Носещи шейни
      • Лавици
      • Кабелни водачи или прикрепващи скоби
    • Захранване – брой на захранванията на единица оборудване – необходимо е, за да се предвидят достатъчно на брой разклонители. Имайте предвид, че последващото добавяне на разклонители не винаги е удобна опция, а понякога не е възможно без сериозно пренареждане на оборудване, което предполага и прекъсване на услуги
    • Обща консумация в начален и максимален капацитет
    • Брой и вид на мрежова свързаност за всяко оборудване
    • Потенциална необходимост от изграждане на повече свързаности към разпределителни табла в дейта центъра
    • Логистика на оборудването
      • Начална – при инсталация – рампи, подходи, асансьори
      • Експлоатационна – оперативна доставка или съхранение на резервни части (дискове, сървъри, мрежово оборудване) 
      • Достъп до дейта центъра в работно/извън работно време.
    • Упълномощени лица и процедура за идентификация – на място и отдалечено (например телефон, мейл)
    • Имайте предвид, че ако получавате мрежови услуги от трети оператори на територията на дейтацентъра, е необходимо да отчитате правилно точния ангажимент, който дейта център оператора и телеком оператора имат към Вас. Не очаквайте да получите нещо повече или различно от това, което е описано в договора 
  • Направете оценка за цялостната цена на дейта център услугата. Определете TCO (Total Cost of Ownership), като отчитате следните компоненти
    • Цена на колокация на оборудване. Обикновено се отчита на 1RU (rack unit) или кратно на капацитет на шкаф
    • Цена за електрическа консумация – може да се смята по номинал на инсталираното оборудване, да се измерва с контролен електромер или да се подава като информация от захранващата система на дейта център оператора 
      • Имайте предвид, че в дългосрочен план цената на електрическата енергия се увеличава. От тази гледна точка е разумно да се заложи на последно поколение оборудване, поради по-голямата му енергийна ефективност 
    • Цена за допълнителни услуги тип “поддръжка на място” (“remote hands”) и какво конкретно се включва в нея
    • Размер и степен на отговорност на оператора на дейта центъра към инсталираното оборудване и предоставяните услуги
Критерии за избор

Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес.

За целите на този документ приемам, че технологичните и финансови параметри на нуждите на организацията са удовлетворени.  Нека разгледаме останалите критерии, които може да определят окончателното решение:

  • Наличие в дейтацентър оператора на капацитет да обслужи нуждите на организацията – например:
    • Персонал като количество и качество
    • Наличие на информационни системи, които реализират, не само необходимата за дейта център/телеком оператора функционалност, но могат да бъдат свързани със съответните системи на организацията
    • Съветваме да проучите дългосрочната финансова и организационна стабилност на дейта център оператора
  • Съвместими организационни култури и ниво на зрялост в дейта център оператора и Вашата организация
  • Потенциал за развитие в оператора, който да гарантира дългосрочното Ви взаимодействие
    • Технологичен потенциал
    • Бизнес потенциал
  • По възможност се насочвайте към оператори, които достатъчно дълго време експлоатират дадена инфраструктура и/или технологично решение.
    • Избягвайте да бъдете първи клиент в нов център или инфраструктура, освен ако SLA, под чиито рамки работите, не позволява поемането на подобен риск
  • Анализирайте SLA предложението. То следва да демонстрира:
    • Постижими за организацията на оператора параметри. Проверете ги. 
      • Потърсете мнение от други клиенти
      • Потърсете мнения по форуми и потребителски групи
    • Зрялост – детайлно разписани отговорности и процес а работа
    • Смислен процес на ескалация – достатъчо нива, но без формално размиване на процеса
      • Плюс е, ако има механизъм, да ексалирате до висш мениджмънт
      • Минус е, ако висшият мениджмънт е необходим на всяка стъпка в процеса на офериране, преговори, предоставяне на услуга, експлоатация
    • Достатъчно точки за недвусмислен контрол –
      • Конкретни количествени критерии за качество и наличност
      •  Възможност за независимо измерване на количествените параметри
      • Интерфейс за наблюдение в реално време на параметри, които са в контрол на оператора (например електрическа консумация)
  • Дейта център операторът следва да предостави ясна и изпълнима процедура по сигурността 
Планиране и изпълнение
  • След доставка, оборудването се проверява за комплектовка и електрическа работоспособност от екип на организацията
    • Имайте предвид, че дори при използване на ново (или дори вече работило във Вашата инфраструктура) оборудване, са възможни проблеми или неработещи компоненти
    • Планирайте с излишък от време
  • Оптимално е монтажът на оборудването в дейта центровете да се извършва от обучен персонал на дейта център оператора под Ваш методически контрол и съгласно предварително съгласувана инструкция за монтаж, маркировка на оборудване и свързващи кабели
  • Фиксирането на оборудването, захранващите и мрежови кабели, се извършва съгласно добрите практики и конкретните особености на използваните шкафове за оборудване, кабелни разпределителни системи и захранващи системи
  • Монтажът на оборудването следва да отговаря на изискванията за лесен достъп за профилактика и процедури за добавяне на нови модули – например памет и дискове. Изваждането на сървър за профилактика, сервиз или добавяне на модули следва да се извършва без необходимост от прекъсване работата на останалите сървъри, като подвеждането на захранващи и комуникационни кабели трябва да изключва или намалява до минимум риска от неволно прекъсване или влошаване на устойчивост на свързване
  • Използват се само фабрично произведени и тествани преди монтаж захранващи и комуникационни кабели
  • След физически монтаж се пристъпва към електрическо оживяване и проверка за правилно свързване към захранващите А и Б подсистеми. Идентифицират се предпазителите осблужващи конкретните сървъри и шкафове
  • Описва се местоположение, маркировка, комуникационни и захранващи кабели за всяко оборудване, както и местоположението на предпазителите на електроразпределителното табло и направените комуникационни кроскънекти
  • Добра практика е документацията да се подготвя в процеса на инсталация, отколкото да се разчита на спомени от трети лица
Успешна експлоатация

Минимално необходимо е:

  • Поддръжка на актуална документация
  • Регулярни контакти с дейта център оператора
  • Регулярни посещения (несвързани с проблеми) в дейта центъра
    • Необходими са, за да имате наблюдения върху развитието на оператора и да получите ранна и изпреварваща информация за потенциални организационни и/или финансови проблеми
  • Изграждане в организацията на Оперативен център, който осигурява тотален мониторинг и контрол на всички параметри свързани със:
    • SLA на дейта център оператора към организацията 
    • SLA на организацията към нейните вътрешни и външни клиенти
  • Връзка между тикетинг системата на организацията и съответния и аналог в Дейта център и телеком операторите
  • Поддържане на актуални процедури за действие в случай на отказ на оборудване, свързаности или дейта център. Тестове на оборудване и действия на персонал в случай на необходимост
За повече информация:
Съвети към IT мениджъра:
  • Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес
  • Доколкото смяната на дейта център е изключително тежко, времеемко и с множество скрити разходи упражнение, добрият избор е от бизнес критично значение

Решения за бекъп и архивиране

Принципи и технология

Системата за архивиране отговаря за надеждното съхраняване на архивни копия на работните данни и системи. Архивирането представлява не само процедура за запазване на архивни копия през определени интервали от време, но осигурява комплекс от мерки, които се предприемат, за да се осигури възможност за възстановяване при системен срив, хакерска атака, бедствия.

  • Пазят се:
    • Архивни копия на данни
    • Виртуализирани системи
    • Конфигурации на системи и услуги
  • По време на експлоатацията на системата се правят:
    • Периодични моментни снимки (snapshots) на системите заедно с работните данни
    • Моментни снимки преди конфигурационни промени
    • Периодични, дневни, седмични и месечни архивни копия
Възстановяване на операциите при срив

Организира се по следният начин:

  • Определяне причина за срив, за да се гарантира интегритета на системата, нейните функции и натрупани данни
  • Изключително важно е да се установи причината за настъпил срив (примерно, ако се използва за маскиране на евентуална хакерска атака). За постигане на целта се прави анализ на натрупаната системна лог информация
  • Работните системи се възстановяват от моментните снимки, за да се осигури бързо преминаване към нормален работен режим
  • Последващо се прави анализ за интегритет на данните, за да се гарантира, че няма изпуснати събития
  • При нужда се възстановяват копия от системните данни през системата за архивиране
Оптимални характеристики на системата за архивиране и бекъп
  • Бизнес клас решение дори на база отворен код
  • Бекъп пространство за съхранение на цялостни и инкрементални резервни копия на всички бази данни и системни компоненти
  • Автоматизирани резервни копия– предварително дефинирано разписание
  • Отворени формати – добра практика е възстановяването на данните да е възможно дори при разрушена инфраструктура – неработещ бекъп сървър
  • Поддръжка на всички разпространени операционни системи, най-малко на използваните в организацията
  • Поддръжка на бекъп върху дискове, ленти, автоматизирани библиотечни системи, клауд базиран сторидж
  • Компресия и дедупликация на данни
  • Криптиране при клиента (end to end encryption)
За повече информация:
Съвети към IT мениджъра:
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

BareOS Backup

Кратко описание

BareOS (Backup Archiving Recovery Open Sourced) e бекъп система за архивиране с отворен код за хетерогенни системи (работни станции, сървъри, различни операционни системи и приложения)

BareOS е вариант (fork) на Bacula поддържа всички нейни функции и възможности като се отличава с по-динамично развитие.

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • BareOS поддържа Linux, UNIX, Windows и macOS архивиращи клиенти и редица професионални архивиращи устройства, включително лентови библиотеки
  • Има комерсиална версия и разширена поддръжка
  • BareOS позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Добре направена документация с множество примери
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Необходимо е сериозно планиране и проектиране на бекъп система базирана на BareOS
  • Предлага ентърорайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • BareOS поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място
За повече информация:
Защо BareOS:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
Недостатъци:
  • Няма много материали на български език
  • В безплатната версия на BareOS:
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения
Оценка на необходимите ресурси при внедряване:
  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
Степен на завършеност на решението:
  • Завършено решение
Съвети към IT мениджъра:
  • BareOS позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Bacula Backup

Кратко описание

Bacula е бекъп система за архивиране с отворен код за хетерогенни системи (работни станции, сървъри, различни операционни системи и приложения)

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • Bacula поддържа Linux, UNIX, Windows и macOS архивиращи клиенти и редица професионални архивиращи устройства, включително лентови библиотеки.
  • Има комерсиална версия и разширена поддръжка
  • Bacula позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Добре направена документация с множество примери
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Необходимо е сериозно планиране и проектиране на бекъп система базирана на Бакула
  • Предлага ентърорайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Бакула поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране.
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място
За повече информация:
Защо Bacula:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
Недостатъци:
  • Няма много материали на български език
  • В безплатната версия на Бакула:
    • Относително бавно развитие, особено забележимо при уиндоус клиентите
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения
Оценка на необходимите ресурси при внедряване:
  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
Степен на завършеност на решението:
  • Завършено решение
Съвети към IT мениджъра:
  • Bacula позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Amanda Backup

Кратко описание

AMANDA (Advanced Maryland Automatic Network Disk Archiver) е една от най-пълните и дългосрочно развивани бекъп системи.

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • Има комерсиална версия и разширена поддръжка
  • Amanda позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Аманда е добре документирана
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Amanda предоставя уникална възможност за едновременно записване на архиви на лента и диск. Така данните могат да бъдат съхранявани на диск за бързо възстановяване и на лента за особено дългосрочно съхранение
  • Amanda не използва собствени драйвери за устройства, като следствие – всяко устройство, поддържано от операционна система, работи добре с Amanda.
  • Проектът с отворен код Amanda се поддържа от голяма и продуктивна общност
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Amanda поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране.
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място

За повече информация:

Защо Amanda:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Amanda поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране
  • Аманда архивите могат да се възстановят и ръчно, тъй като са копие на файловите системи на хостовете, които се архивират с tar. Т.е. Amanda архив е възстановим, дори без инсталация на Аманда сървър

Недостатъци:

  • Няма много материали на български език
  • Безплатната версия няма уеб базирана конзола за управление
  • В безплатната версия на Аманда:
    • Относително бавно развитие, особено забележимо при уиндоус клиентите
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения

Оценка на необходимите ресурси при внедряване:

  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
  • Поддръжката на Аманда бекъп решение предполага квалифицирани систрмни администратори
Степен на завършеност на решението:

  • Завършено решение
Съвети към IT мениджъра:

  • Amanda позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Security Onion Hybrid Hunter

Кратко описание

Security Onion Hybrid Hunter е следващата версия на Security Onion и текущо е в алфа тест. Отделям внимание на този незавършен продукт, защото като замисъл тази версия трябва да отстрани основните недостатъци на SO и може би си струва да се изчака и евентуално използва SO HH за реализация на мащабни open source SIEM системи в големи организации. 

За повече информация:
Защо Security Onion Hybrid Hunter:
  • SO-HH вероятно ще реши проблемите на SO като добави интегрирани възможности за корелация, анализ и управление на действия
  • В допълнение – модерната, базирана на контейнери архитектура на HH, би могла да предопредели дълъг живот и улеснена поддръжка на системата
Недостатъци:
  • На този етап е рано да се прецени
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO HH представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 4-8 часа
  • Разширени конфигурации – рано е за оценка
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Ранна алфа версия
  • Множество проблеми
Съвети към IT мениджъра:
  • Изчакайте. SO HH може да е добра основа за изграждане на SIEM решение за Вашата организация. 
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Security Onion

Кратко описание

Security Onion е SIEM (Security Information and Event Management) система с отворен код и представлява Linux дистрибуция за откриване на прониквания, наблюдение на сигурността на организацията и управление на логове. Основни функции:

  • Събиране на информация от мрежата в реално време (full realtime packet capture)
  • Мрежови и хост-базирани системи за откриване на проникване (NIDS и HIDS)
  • Мощни инструменти за анализ

Включва:

  • ELK Stack – Elasticsearch, Logstash, Kibana – събиране, съхранение, обработка и визуализация на информация
  • Snort – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Suricata – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Bro – използва се като система за откриване на проникване базирана на анализ (Analysis driven IDS  – Intrusion Detection System)
  • OSSEC – хост базиранa системи за откриване на проникване (HIDS)
  • Wazuh – използва се като система за откриване на проникване в сървъри (Host based IDS  – Intrusion Detection System)
  • Sguil – Система за анализ
  • Squert – Уеб интерфейс към Squil
  • И много други инструменти за сигурност

Security Onion представлява колекция от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Поддържа агенти, които могат отдалечено да събират и изпращат информация към разпределената система за обработка и визуализация. SO предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
  • Управление информационната сигурност на голяма организация – SO позволява изграждането на разпределена система от колектори, процесори на информация и сторидж системи
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси
За повече информация:
Защо Security Onion:
  • Зрял проект с дългогодишно развитие и широка база от разработчици на много от неговите компоненти
  • Предлага съществена функционалност в безплатна версия
  • За разлика от конкурентни продукти (например AlenVault OSSIM) има вграден и много добър механизъм за събиране, обработка и визуализация на логове (ELK stack)
  • Има комерсиална поддръжка
  • Безплатната версия има относително добра документация, както и някаква поддръжка от общността на потребителите
Недостатъци:
  • Макар положените усилия за сглобяване и интегриране на различните средства, дистрибуцията е доста насипна и еклектична комбинация от отделни продукти, които в повечето случаи се конфигурират и управляват през множество разположени във файловата система конфигурационни файлове без единен интерфейс
  • Макар да решава много задачи,  SO не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Липсват възможности за организиране на йейрархии и управление на действия при секюрити събития
  • Липсва единен механизъм за изпращане на алерти
  • Редки ъпдейти
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации са в зависимост от мащаба на организацията и може да са необходими много дни за постигане на удовлетворяващи резултати
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Насипно решение.
  • Някои компоненти работят добре и веднага, други изизкват много време за конфигурация. 
Съвети към IT мениджъра:
  • Security Onion е добра начална стъпка за осигуряване на информационна сигурност в голяма организация и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на SO в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате добри системни и мрежови администратори, R&D персонал и достатъчно време да поддържате насипно решение от различни компоненти с отворен код – по-скоро рано, отколкото късно – ще се наложи да търсите и мигрирате към комерсиално решение ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

AlienVault OSSIM

Кратко описание

AlienVault OSSIM (Open Source Security Information Management) е SIEM (Security Information and Event Management) система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Понастоящем, AlienVault OSSIM е част от AT&T Cybersecurity. 

OSSIM не само събира различни средства с отворен код, но ги интегрира в общ интерфейс за управление, обмен на данни, възможност за корелиране на събития и управление на инциденти свързани със сигурността. Така OSSIM предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

AlienVault OSSIM има автоматизирани механизми за събиране на инвентарна (сканиране на мрежи, детекция на операционни системи, работещи услуги) и лог информация. Сканира за уязвимости, управлява събития, техния контекст и взаимна корелация. Генерира аларми, предписания и ескалира действия в рамките на SOC (Security Operations Center) на организацията. 

Чрез активиране на сървър и агенти в различните офиси/локации на организацията, може да се обхване цялостната и дейност в единна система. 

Компоненти:

  • PRADS – използва се за идентифициране на хостове и услуги чрез пасивно наблюдение на мрежовия трафик
  • Suricata – използва се като система за откриване на проникване (IDS  – Intrusion Detection System)
  • Tcptrack – използва се за анализ на данни от TCP сесии, да предоставя полезна информация за корелиращите механизми
  • Munin – използва се за трафичен анализ и наблюдение на услуги
  • NFSen / NFDump – използва се за събиране и анализ на NetFlow 
  • FProbe – използва се за генериране на NetFlow от уловен трафик
  • Nagios – използва се за наблюдение на хостове и услуги
  • OpenVas – използва се за оценка на уязвимостта на наблюдавани хостове и услуги
  • В допълнение OSSIM включва разработени от AlienVault инструменти, като най-важният е генерален механизъм за корелация с логическа поддръжка на директиви и обработка на лог информация със специализирани процесори
Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси. 
  • Управление информационната сигурност на голяма организация – същественото ограничение е, че OSSIM обработва информацията само на един сървър
За повече информация:
Защо OSSIM:
  • Зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага доста от необходимата функционалност в безплатната версия
  • Има комерсиална версия с повече възможности и разширена поддръжка
  • Безплатната версия има много добра документация, както и достатъчно надеждна поддръжка от общността на потребителите
  • Много добра документация, включително обучаващи клипове и редовни уебинари по различни аспекти на информационната сигурност
Недостатъци:
  • OSSIM е opensource вариант на комерсиален и скъп продукт, има мек натиск за преминаване към платената версия
  • Макар да решава много задачи, OSSIM не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Съществуват дребни (но отнемащи време на администраторите на OSSIM) проблеми, които не се отстраняват с години. Все пак следва да се отчита, че големите проблеми се отстраняват достатъчно бързо
  • Редовните ъпдейти на OSSIM – няколко пъти седмично, отнемат доста време и понякога се налага отстраняване на проблеми предизвикани от самия ъпдейт
Оценка на необходимите ресурси при внедряване:
  • Тъй като OSSIM представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации, включително дефинирането на необходимите за спецификата на организацията корелационни правила, отнема време в зависимост от мащаба на организацията и може да отнеме дни
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Завършено в голяма степен решение, но в безплатната версия липсат необходими компоненти – например сървър за запазване и обработка на историческа лог информация
  • Необходимо е дефиниране нужните на организацията корелационни правила
Съвети към IT мениджъра:
  • Струва си – AlienVault OSSIM е добра начална стъпка за осигуряване на информационна сигурност и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на OSSIM в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате R&D персонал и достатъчно време да създавате корелатори на събития и отчети за конкретните си нужди на – по-скоро рано, отколкото късно – ще се наложи ИЛИ да преминете към комерсиалната версия ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

OpenNebula

Кратко описание

OpenNebula е мощно и гъвкаво решение с отворен код за изграждане, оркестрация и експлоатация на частни и хибридни виртуализационни и клауд решения. Позволява работа в режим инфраструктура като услуга (IaaS).

Използват се KVM, LXD и Vmware хипервайзори. Поддържа инфраструктура разположена в един или множество дейта центрове. Позволява виртуализация на ниво центрове за данни и/или облачна инфраструктура.

OpenNebula е софтуер с отворен код и Apache лиценз.

OpenNebula оркестрира сторидж, мрежа, виртуализация, мониторинг и сигурност. Разполага с инструментариум, включващ интеграция, управление, мащабируемост, сигурност и акаунтинг на предоставяните услуги. ОпънНебюла поддържа и съчетава множество йерархии от потребители и услуги (multitenancy), като осигурява съвместната работа, управление на споделени ресурси, отказоустойчивост (High Availability), възстановяване от срив (Disaster Recovery).

OpenNebula може да се използва за управление на виртуални дейта центрове, федерация на дейта центрове и хибридни решения. Заради поддържаните отворени и частни стандарти, OpenNebula позволява изграждане на хибридни решения в Amazon EC2, OpenStack, GCP.

Подходящ за:
  • Оркестрация на виртуализация на ниво голям бизнес, клауд провайдър и телеком провайдър 
Неподходящ за:
  • Решения за малък бизнес
  • Оркестрация на контейнери (изключение LXD контейнери)
За повече информация:
Защо OpenNebula:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Интегрирано решение за High Availability / Disaster Recovery
  • API за връзка с трети продукти
Недостатъци:
  • Липса на интерирано бекъп решение
  • Липса на интегрирано управление на сторидж 
  • Поддържа само LXD контейнер технология, няма директна поддръжка на Docker и Kubernetes. Т.е. те могат да се инсталират във виртуални машини под OpenNebula управление
  • Макар да има средства за визуализация на основни метрики на OpenNebula клъстера и поддържаните виртуални машини, контейнери и сторидж има какво да се желае в това отношение и е необходимо да се интегрира с продукти като Zabbix / GrayLog / Grafana, за да има функционални и богати средства за мониторинг на състоянието на клъстера и услугите
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 12-24 часа.
    • Необходимост от оперативна поддръжка: ниска до средна (под 6 часа месечно) за системи до 5 физически сървъра и 50 виртуални машини
  • Инсталация на OpenNebula – доста насипна, особено при клъстеризиране на системата за управление 
Степен на завършеност / Необходимост от развитие:

  • Комплексно решение с множество компоненти, които следва да се настроят и интегрират за съвместна работа
Съвети към IT мениджъра:
  • Подходящо е за решения в широк спектър – от няколко до хиляди сървъри, разположени в един или множество дейта центрове
  • OpenNebula е особено подходяща при изпълнение на някой от следните сценарии или произволна комбинация от тях:
    • Мащабни решения с поддръжка на множество дейта центрове
    • Изграждане и използване на хибридни клауд (hybrid cloud) решения – комбинация от частна инфраструктура на организацията и интерфейс за оркестриране на виртуализация върху публични клауд решения (например Amazon EC2)
    • Интеграция (например поради причина оптимизация на разходи) в единна система на различни хипервайзор технологии от бизнес клас (например VmWare) и Open Source  (KVM или Xen) 
  • Поради комплексния характер на OpenNebula и сценариите за използването ѝ, кривата на обучение е доста разтеглена и е необходимо наличие на администратори с много опит
  • Необходимо е да се разработят и/или интегрират допълнителни компоненти, за да се разполага с напълно развита OpenNebula система (Backup, Storage, Containers)
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата

ISPConfig

Кратко описание

ISPConfig е широко използван хостинг контролен панел (аналог на популярното комерсиално решение cPanel) с отворен код за Linux.

В тази статия разглеждам ISPConfig не толкова като контролен панел за хостинг провайдъри (работа, която той върши прекрасно), а като интегрирано и изключително удобно решение за управление интернет ресурсите на организация или бизнес. 

ISPConfig позволява на администраторите да управляват през единен уеб интерфейс уебсайтове, мейл сървъри, мейл интерфейси, бази данни MySQL и MariaDB, FTP сървъри, shell достъп, и DNS сървъри.

Тъй като е предназначен за хостинг провайдъри, ISPConfig поддържа йерархия на достъп в категории администратор, продавач, клиент и имейл потребител. Тази структура лесно се пренася и е изключително удобна и за управлението на ресурси в голяма организация с развита йерархия, но същевременно не пречи и не усложнява работата на малки организации. 

За разлика от популярен комерсиален продукт като cPanel, ISPConfig поддържа повече Linux дистрибуции  – CentOS, Debian, Fedora, OpenSUSE и Ubuntu

Поддържат се следните услуги и функции:
  • Управление на единичен или отказоустойчив клъстер от няколко сървъра през един контролен панел
  • Управление на уеб сървъри (Apache и Nginx)
  • Управление на мейл сървър (с виртуални пощенски кутии с антиспам и антивирусен филтър) Postfix и Dovecot
  • Управление на DNS сървър (BIND, Powerdns)
  • Управление на виртуални сървъри (OpenVZ)
  • Статистика за уебсайтове  (Webalizer и AWStats)
  • Софтуерен каталог с автоматична инсталация на уеб приложения (например WordPress)
Подходящ за:
  •  Управление на интернет ресурси на организация
Неподходящ за:
  • Изграждане на ентърпрайс клас уеб базирани информационни системи
За повече информация:
Защо ISPConfig:
  • Добре направен и много добре интегриран интерфейс към популярни софтуери за изграждане на интернет присъствие – 
    • DNS, Web, FTP, Mail, Antispam, Antivirus 
  • Достатъчно широка общност от разработчици и потребители
  • OpenSource решение
Недостатъци:
  • Няма вградена интеграция с LDAP или Active Directory (AD), за използване в корпоративна среда, но такава е възможно да се направи допълнително
Оценка на необходимите ресурси при внедряване:
  • Хардуер – в зависимост от нуждите и размера на организацията
  • Софтуер – инсталацията е добре документирана, има и скриптове за автоматизация – отнема около 1 час
Степен на завършеност на решението:
  • Завършенo решения
Съвети към IT мениджъра:
  • Поради добрата интеграция и единно управление на основни интернет ресурси си струва да се използва както при малки, така и за големи организации
  • Добре работи във виртуализирана среда, тоест не се налага използване на отделен сървър
  • Улеснява работата на IT отдела в организацията чрез интегрирано управление на интернет услуги през уеб интерфейс
  • Улеснява и ускорява провизирането (буквално няколко клика) на нови open source уеб приложения за нуждите на организацията, например: CRM, ERP, CMS (WordPress), Accounting, Billing, HR, Knowledge management, Support, Ticketing, Collaboration, Productivity, e-commerce, forums and bulletin boards).

OpenVPN

Кратко описание

OpenVPN е комерсиален софтуер с отворен код, който реализира техники за създаване на виртуална частна мрежа (VPN) и провизиране на сигурни връзки от точка до точка или между сайтове и локации на дадена организация (site to site VPN) Използва SSL / TLS за обмен на ключове. Работи добре и преминава пре NAT. 

OpenVPN позволява на участниците в комуникацията (независимо дали  клиент/сървър или сървър/сървър топология) да се удостоверяват взаимно, като използват предварително споделени секретни ключове, сертификати или потребителско име / парола. 

OpenVPN работи като самостоятелен сървър под дадена операционна система или като елемент от мрежови аплайънс (обикновено файъруол) като PfSense. В тези случаи има и добра интеграция със системи за генериране на ключове и сертификати, потребители, както и механизъми за разпространението на сертификати и ключове.

Разработен е и активно се поддържа за платформи като: 

  • Windows
  • Linux
  • Solaris
  • OpenBSD
  • FreeBSD
  • NetBSD
  • QNX
  • MacOS
  • Android
  • IOS
Подходящ за:
  • Целият спектър възможни приложения за играждане на VPN
    • От изграждане на персонално VPN решение 
    • До изграждане на хетерогенна виртуална инфраструктура на организация с много локации и/или използване на ресурси в публични и частни клауд инфраструктури
Неподходящ за:
  • Практически няма сценарий, който не може да изпълни, макар да липсват някои улеснения, които се предлагат от комерсиалните решения
За повече информация:
Защо OpenVPN:
  • Зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага пълна функционалност в основна безплатна версия
  • Има комерсиална поддръжка, както и достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлагат се завършени решения – интеграция на OpenVPN с firewall решения като PfSense 
  • Скалируемо решение – клъстер за постигане на висока производителност и отказоустойчивост
  • Много добра документация
Недостатъци:
  • Многото възможности на OpeVPN, го правят комплексен и сложен за конфигурация и поддръжка продукт
    • В тази връзка и ако използването на комерсиалните OpenVPN сървъри не е вариант, то подходящо решение е PfSense
Оценка на необходимите ресурси при внедряване:
  • Инсталацията на OpenVPN и базовата функционалност като VPN сървър е лесна, не изисква особена експертиза и има множество добре написани инструкции и видео материали по темата
  • За разширена функционалност и комплексна инфраструктура е необходима експертиза за мрежова сигурност и системна администрация
  • Поддържа се всякакъв хардуер – т.е. в зависимост от нуждите може да се използва наличен или специализиран хардуер за постигане на висока производителност
    • Следва да се има предвид необходимостта от използване на по-модерни процесори (поддържащи AES-NI  набор от инструкции) при необходимост от поддръжка на криптирани потоци с висока скорост
    • При необходимост от поддържане на голям брой едновременно работещи потребители – по-добър вариант е провизиране на повече VPN сървъри работещи върху един физически сървър, отколкото инсталация върху много отделни сървъри
Степен на завършеност на решението:
  • Напълно завършено решение
Съвети към IT мениджъра:
  • Тъй като експлоатацията на OpenVPN предполага по-високо ниво на познания в областта на мрежовата защита, наличието на минимално необходимата квалификация в екипа е задължителна
  • Постигането на желаната производителност е следствие от добро проектиране, изпълнение и правилна експлоатация
  • Добре се виртуализира и може да се използва за изграждане на хетерогенна виртуална инфраструктура на организация с много локации и/или използване на ресурси в публични и частни клауд инфраструктури
  • Никога не считайте, че използването на каквато и да е технология за защита, е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Ceph

Кратко описание

Ceph е софтуерно дефиниран сторидж базиран на отворен и свободен код. Неговата разпределена архитектура съхранява данните върху множество сървъри и така не допуска единични точки на отказ. Мащабируем е до екзабайт ниво и има смисъл да се използва дори за малки обеми от данни в порядък на няколко терабайта. 

Ceph поддържа няколко копия на данните върху множество дискове и сървъри, които могат да бъдат разположени в различни локации с цел постигане на по-висока отказоустойчивост. Тъй като Ceph:

  • Използва стандартни сървъри
  • Няма необходимост от RAID контролери
  • Поддържа хетерогенна инфраструктура (сървъри и дискове от различни поколения, с различен капацитет и производителност)

Изгражданите сторидж решения се характеризират с дълъг живот, ниска цена за хардуер, ниски оперативни разходи и оптимално използване на хардуера. Следва да се отчита, че хетерогенната инфраструктура е пречка за постигане на върхова производителност. 

Ceph:

  • Е зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага пълна функционалност в основна безплатна версия
  • Има комерсиална поддръжка, както и достатъчно подробна и надеждна поддръжка от общността на потребителите
Подходящ за:
  • Изграждане на надеждни сторидж системи с висока производителност
  • Решения в спектъра терабайтов до екзабайтов сторидж
Неподходящ за:
  • Маломерни решения – административният овърхед е твърде висок, а при малки инсталации е трудно да се постигне висока производителност. 
За повече информация:
Защо Ceph:
  • Изключително скалируемо решение
  • Ниска TCO (Total Cost of Ownership) обща експлоатационна цена. 
  • Изключително надеждна и отказоустойчива платформа
  • Много добра документация
Недостатъци:
  • Тъй като е надежден и лесен за начална конфигурация, цялата комплексност на ceph се възприема в наистина критични моменти, ако има сериозен срив
  • Високата производителност се получава на съответната цена
  • Принципно Ceph клъстерът е относително толерантен към хардуерни проблеми (отпадане на дискове, мрежа, сървъри), но по разбираеми причини това трябва да се избягва. Вероятността от загуба на данни е малка, но е възможно клъстерът да премине в режим на проверка за проблем и поправка – изключително натоварващ процес, който забавя възстановяванто на нормалните операции след повторно включване.
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Инсталация на ceph – относително сложна, по- при използване на базови настройки за малка до средна инфраструктура – лесна
  • Добре се вписва в налични среди за виртуализация – поддържа се от основни системи като ProxMox, OpenNebula, OpenStack
  • Капацитетът и производителността на Ceph са в практически линейна зависимост от броя на използвани дискове и сървъри
  • При определяне политиката за репликация на данните – може да се приеме коефициент на репликация 2 за по-маловажни и 3 за важни данни
  • 10GB/e е минималната смислена мрежова свързаност в клъстера. За по-добър пърформанс е препоръчително преминаване на по-високи скорости 25GB/e, 40GB/e и повече. Дублирането на мрежовите връзки е от съществено значение за повишаване отказоустойчивостта, а като позитивен страничен ефект и на производителността. 
  • По-голям брой дискове гарантират по-висока отказоустойчивост и производителност
  • Използването на SSD или по-добре PCIe / NVME дискове е препоръчително
Степен на завършеност на решението:
  • Напълно завършено решение
Съвети към IT мениджъра:
  • Ceph позволява изграждане на ентърпрайс клас скалируемо и откзоустойчиво сторидж решение без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Изключителната надеждност на Ceph води до липса на тренинг и умения за възстановяване след реален срив.
  • Експлоатацията на Ceph клъстер в хиперконвергентна архитектура изисква следене използването на хардуерните ресурси (памет, процесор) от сторидж и hypervisor подсистемите. При необходимост следва да се предприемат мерки за осигуряване на достатъчни ресурси за Ceph, за да не се наблюдава обща деградация на производителността за целия клъстер. 
    • От тази гледна точка, за постигане на максимална производителност е необходимо Ceph да работи самостоятелно върху заделени за целта сървъри
  • Постигането на желаната производителност е следствие от добро проектиране, изпълнение и правилна експлоатация. Поддръжката на Ceph предполага обучен персонал с опит или достатъчно време и възможност за натрупването му. 

IT инфраструктурата на стартираща компания

IT инфраструктурата на стартираща компания

Организация. Принципи. Решения. Управление на риск

1. TL;DR
  • Описани са съображения, принципи и правила при проектиране изграждане и експлоатация на IT инфраструктурата на стартираща компания;
  • Фактори за постигане максимална ефективност при оптимална цена;
  • Управление на IT рискове на стартиращата компания чрез избор на подходящи и изпитани решения;
  • Съвети за идентифициране на проблеми и пестене на време и нерви;
  • Препоръчват се изпитани решения базирани на отворен код.
2. Въведение

Настоящият документ е насочен основно към IT нуждите на технологична компания, но принципите и дизайн насоките са валидни за широк кръг компании, които по необходимост изграждат комплексна IT инфраструктура.

Водещи принципи –

  • Изграждане на необходимата IT инфраструктура, експлоатация гарантираща запазване на интегритет и пърформанс в работата на организацията
  • Оптимизиране на оперативните разходи при различни схеми на организация, включително с присъствени и отдалечени работни места.
  • Внедряване на изпитани решения, за които е натрупан достатъчно експлоатационен опит

Описват се основните положения и добри практики при проектиране и изграждане на виртуализирана, евентуално хиперконвергирана инфраструктура

Целта на документа е да предложи ефективно решение, което може да поддържа дейността на компании от всякакъв мащаб, като гарантира плавно развитие на инфраструктурата съобразно бизнеса на организацията.

Съдържание на: IT инфраструктурата на стартираща компания

The IT infrastructure of Startup company - CONTENTS

 

Можете да получите целия документ след регистрация.

Вашите лични данни ще бъдат обработени съгласно Условията на сайта.

Съгласно Условията на сайта, имате пълни права за използване на файла и информацията в него при съблюдаване на Creative Commons CC BY-SA лизенза. 

 


    Съгласен


    DevOps Roadmap 2020

    Кратко описание

    Това, според Kamran Ahmed, е DevOps технологичният стек за началото на 2020г. 

     

    Съвети към IT мениджъра:
    • Без претенции за всеобхватност и валидност за целия devops спектър, схемата дефинира примерен модел, който може да се следва от технологичните организации за изграждане и поддържане на модерна IT инфраструктура
    • Схемата е особено подходяща за фукционална визуализация на devops и sysadmin процесите в организацията и идентифицирането на необходимите ресурси и технологично ноу-хау
    • Препоръчително е CIO и IT мениджърите да имат предвид или да разработят подобна схема, която да подпомага процеса на търсене на нови и обучение служителите на организацията
    • Не че е невъзможно, но не е препоръчително да реализирате целия технологичен стек без по-тясна специализация и разпределение на роли в екипа