Описание и обосновка на проблемите при миграция към софтуерна монокултурна среда на СУ. екип на курса "Мрежова сигурност" Настоящото (? писмо) бе написано по повод стратегията за миграция на Софийския Университет (която се намираше на http://shuttle.ucc.uni-sofia.bg/su-infrastructure.htm , в момента архивно копие може да се намери на http://vasil.ludost.net/fmi/su-infrastructure.htm. Там се описва решение, изградено върху монокултурна среда (т.е. само на една платформа). Поради сериозността на проблемите, които се пораждат от един такъв подход в толкова голяма мрежа, изпращаме този документ, за да Ви запознаем с тях и с опасностите, породени от една такава стратегия. Проблемите могат да се разделят в следните категории: 1. Проблеми със сигурността 2. Vendor lock-in 3. Ограничаване на възможностите Ще се спрем на всяка категория поотделно. 1. Проблеми със сигурността В последните няколко години зачестиха атаките от т.нар. 'червеи' - злонамерени програми, които използват някакъв пропуск в сигурността на определена среда, за да се разпространяват. Те са ориентирани към определен продукт, и вредата, която нанасят, е правопропорционална на количеството инсталации на този продукт. Има много изследвания, които описват и обосновават опасността от създаването на среда, в която преобладава много сериозно определен продукт, най-известното от които е "CyberInsecurity: The Cost of Monopoly", издадено от Computer & Communications Industry Association (CCIA, http://www.ccianet.org/) (документът може да бъде намерен на http://www.ccianet.org/papers/cyberinsecurity.pdf). Важно е да отбележим, че документът се базира на изследвания в реалния живот, и на наблюдението на много "червеи", резултатите от които стигнаха и до пресата. Като примери могат да се посочат Code Red, Slammer (разпространил се в такава степен, че да успее да прекъсне задръсти връзката до някои държави, например Северна Корея), Melissa (създал огромни проблеми на американските военни), и Sobig.F (определен като най-бързият червей, разпространяващ се по електронна поща, прекъснал работата на много сървъри за електронна поща). 2. Vendor lock-in Терминът няма буквален превод на български, но може да се обясни по следният начин - това е ситуация, в която продуктите на даден производител работят само с продукти на този производител, принужадавайки ни да ползваме само него. Можем да направим следната аналогия - ако сме си купили хляб от съседния магазин, да не можем да си купим масло, което да намажем на хляба от друго място. Изграждането на такива монокултурни решения и vendor lock-in са много тясно свързани, и много често вървят заедно. Така се проявява гамата проблеми, за която говорим - оказваме се обвързани с точно една компания, и можем единствено да се надяваме, че решенията, които тя ще взема за в бъдеще, няма да ни повлияят отрицателно. Много добър пример дават различни производители на софтуер, които са изградили подобни решения, след което фалират, или решават, че този софтуер за тях не е печеливш, и спират поддръжката, което оставя потребителите с много малко поле за избор - или да купят от същия производител друго решение, което да отговаря на нуждите им (ако има такова), или да преразгледат цялата си стратегия и мрежа, и да мигрират към нещо различно, което в подобни монокултурни среди е много трудно, скъпо, и в зависимост от продукта може да отнеме до няколко години (например ако продуктът е операционна система). 3. Ограничаване на възможностите. Този проблем е свързан с предишния, но заслужава отделна точка, поради сериозните му последици, особено за образователна институция. Използването на монокултурна среда ограничава възможностите за използване на нововъведенията в областта на софтуера. Така се стеснява гледния хоризонт на хората, използващи този софтуер, което е особено вредно за учащите се. Като заключение бихме искали да кажем, че според нас една балансирана софтуерна среда би била най-полезна и целесъобразна за нуждите на учебно заведение от калибъра на Софийския Университет.