Cloud nebo server?

[Karbous]

Drive se nahravala data a dokumenty na server. Ted je moderni nahravat data a dokumenty na cloud.
Potreboval bych poradit jaky je v tom rozdil.
Momentalne mam predstavu ze cloud = server + nejaka cool serverova aplikace neco jako samba s nejakym coool web pristupem a databazi. Tedy, ze je to v podstate stejne, jen se tomu jinak rika, aby se to prodalo.
Mylim se prilis?
 

[Reklama]

[Tomáš Crhonek]

Je to jen marketing.

Kdysi dávno to znamenalo, že svá data nahrajete na nějakou službu a prakticky vás nezajímá, na kterém fyzickém serveru (či spíše na kterých fyzických serverech v replikách) dané služby to skončí. Příště se připojíte třeba na úplně jiný vstupní server stejné služby a svá data tam uvidíte. Služba si to interně zařídí jak potřebuje, vy máte k disposici jednu adresu a nějaké api pro přístup k datům.

Jenže debilové z obchodních oddělení ucítili příležitost, takže se postupně za cloud začal označovat i jeden disk připojený k síti, který exportuje smb, dlna a má nějaký fancy web plný bezpečnostních chyb.

[PetrM]

No asi takhle:

Server: V sídle firmy je rack s nějakým železem. Všechno si to chrochtá interně, IT se stará o stav železa, updaty a zálohy. Ale je jistoa (pokud tam není M$ technologie a děravý firewall), že se z toho nic nedostane ven. A že firma funguje, dokud je elektrika a výpadky konektivity tě nezajímají. Pravidla užívání si nastavíš, jak se ti to zrovna hodí. Při použití IPv6 neví útočník, na jaké IP adrese hledat a scan sítě by trval dýl, než server fyzicky odepíšeš.

Čmoud: Pošleš data jinam. Železo, zálohy a podobně tě nezajímají. Dala ale bloudí kdoví kde. API, veřejný IP adresy k datům a podobně jsou defakto veřejně dostupný, útočník je má jako na talířku (jako ta autentizace u Mrkkvošrotů, jak stačilo na spárovaný LDAP hodit uživatele s mailovou adresou konkurenční firmy). mimo přívodu elektriky jako v prvním případě závisíš i na ISP a provozu služby. Pravidla určuje někdo jiný - větší šance, že přijdeš o data, než když jednou týdně vezmeš z hromádky v tezoru USB HDD, který je na řadě, a uděláš snímek serveru. Jeden obrázek, kde je víc holé kůže, než se robotovi líbí, a máš u M$ smazaný data i s účtem. Filmy a hudba, i legální nebo dokonce vlastní tvorba, jsou na základě přípony pirátění a ruší se za to účet i s daty. Nebo klientská aplikace rovnou prošmejdí PC a zkopíruje a pomaže lokální kopie toho, co se mu líbí a když zrušíš předplatný, přijdeš o to (tuším Apple nebo někdo takový).

Nešel bych do už z principu, aspoň dokud nebude legislativně deklarováno, co si provozovatel čmoudu smí dovolit a za co povinně ručí. Teď si dá do podmínek něco ve smyslu, že za uložený data neručí, nebo nějakou nesplnitelnou podmínku, díky které může cokoliv a není na něho žádná páka, pokud nejsi nadnárodní korporace.

[to_je_jedno]

Ale je jistoa (pokud tam není M$ technologie a děravý firewall), že se z toho nic nedostane ven.

ha ha ha. a jeste jednou ha ha ha. Vsadim se o cokoliv, ze ti mnohem lepe vynesu data ulozeny ve firme nez ulozeny v tom vasem "čmoudu" treba u M$ nebo Google.

Hint: zamestnanci jsou kurvy prodejny - vzdy a vsude se najde nejakej takovej... A kdyz ne tak si ho tam jako utocnik primo nasadim.

[karlik]

Proč bys chtěl vynášet data ze "čmoudu" od M$ nebo Google? Ti už přece ty data mají...
A "nasadit" někoho do firmy = kriminální čin -> soud -> klepeta.

[Reklama]

[čumil]

Ale je jistoa (pokud tam není M$ technologie a děravý firewall), že se z toho nic nedostane ven.

ha ha ha. a jeste jednou ha ha ha. Vsadim se o cokoliv, ze ti mnohem lepe vynesu data ulozeny ve firme nez ulozeny v tom vasem "čmoudu" treba u M$ nebo Google.

Hint: zamestnanci jsou kurvy prodejny - vzdy a vsude se najde nejakej takovej... A kdyz ne tak si ho tam jako utocnik primo nasadim.

Když jsou blbě placený, musej si trošku přilepšit ne ?

A otázka, co konkrétně mění cloud? Tak místo loginu do custom systému dostaneš login do cloudu ...

[Petr M]

Ale je jistoa (pokud tam není M$ technologie a děravý firewall), že se z toho nic nedostane ven.

ha ha ha. a jeste jednou ha ha ha. Vsadim se o cokoliv, ze ti mnohem lepe vynesu data ulozeny ve firme nez ulozeny v tom vasem "čmoudu" treba u M$ nebo Google.

Hint: zamestnanci jsou kurvy prodejny - vzdy a vsude se najde nejakej takovej... A kdyz ne tak si ho tam jako utocnik primo nasadim.

Blbost. Když vím, že jsou data fyzicky v baráku a že k nim někdo šel zevnitř, tak najít ho není problém. Nafekjkuju 20 verzí sdílených dat, pro každýho zaměstnance jinou (stejný soubor, ale s nějakým pozměněným číslem nebo větou v textu) a která projde ven, ten zaměstnanec má padáka, kriminálku a firemního právníka s žalobou o náhradu škody na krku. Když je cestou ještě pět firem s konektivitou a infrastrukturou, lidi u provozovatele čmoudu a pár tisíc anonymních black hatů kolem unifikovanýho API, je hledání viníka mnohem těžší.

A čmoud nijak nezabrání špehovi ani sabotérovi v jeho činnosti. Naopak, přihlásí se odkudkoliv, nejenom z firemního PC přes VPN. Ze zavirovanýho železa s nezablokovaným USBčkem a vypalovačkou, mimo firemní firewall,...

[to_je_jedno]

Nafekjkuju 20 verzí sdílených dat, pro každýho zaměstnance jinou

jj, tohle je urcite nejvetsi starost kterou resi kazdy normalni sef kazde normalni firmy... (a ten sef-ajtak co mu to nastavuje se nikdy s nikym ze zamestnancu nevozral v baru :-) )

ten zaměstnanec má padáka, kriminálku a firemního právníka s žalobou o náhradu škody na krku.

kriminalku? za co presne? firemniho pravnika a nahradu skody? prokazat umysl neni uplne trivialni. padaka? uz jsi nekdy v praxi zkousel dat nejakymu vohnoutovi padaka v tomhle socialistickym absurdistanu?

Proč bys chtěl vynášet data ze "čmoudu" od M$ nebo Google? Ti už přece ty data mají...
A "nasadit" někoho do firmy = kriminální čin -> soud -> klepeta.

Spis je otazka proti komu je vlastne chces chranit? Proti M$ ci Google? Jsou snad tvoji konkurenci?

[podlesh]

Drive se nahravala data a dokumenty na server. Ted je moderni nahravat data a dokumenty na cloud.
Potreboval bych poradit jaky je v tom rozdil.
Momentalne mam predstavu ze cloud = server + nejaka cool serverova aplikace neco jako samba s nejakym coool web pristupem a databazi. Tedy, ze je to v podstate stejne, jen se tomu jinak rika, aby se to prodalo.
Mylim se prilis?

Pojem "cloud" nebyl nikdy úplně jasně definovaný a velmi rychle vyšuměl do synonyma pro "online"

Takže odpověď zní: nemýlíš se.

[lojza]

No, v podání některých firem může znamenat cloud = desktop apka + předplatné

[to_je_jedno]

No, v podání některých firem může znamenat cloud = desktop apka + předplatné

coz je zpravidla vyrazne levnejsi a efektivnejsi nez resit vlastni infrastrukturu...

[PetrM]

Nafekjkuju 20 verzí sdílených dat, pro každýho zaměstnance jinou

jj, tohle je urcite nejvetsi starost kterou resi kazdy normalni sef kazde normalni firmy... (a ten sef-ajtak co mu to nastavuje se nikdy s nikym ze zamestnancu nevozral v baru :-) )

To je jak s mistrem na směně. Může být kamarád s fachmanama, po šichtě s nima chodit do putyky,... Ale hádej, jak to dopadne, když mu jeho šéf řekne "zbav se pěti lidí, nebo letíš ty"?

ten zaměstnanec má padáka, kriminálku a firemního právníka s žalobou o náhradu škody na krku.

kriminalku? za co presne? firemniho pravnika a nahradu skody? prokazat umysl neni uplne trivialni. padaka? uz jsi nekdy v praxi zkousel dat nejakymu vohnoutovi padaka v tomhle socialistickym absurdistanu?

Kriminálka - § 182, § 183 zákona 40/2009 Sb.

Padák
- Alternativa 1: § 55 odst. 1 písm. b) zákona 262/2006 Sb. za předpokladu, že je ve smlouvě specifikován zákaz vynášení dat. Musí při tom postupovat podle §52

- Alternativa 2: §301 písm. d) zákona 262/2006 Sb. ukládá zaměstnanci povinnost "řádně hospodařit s prostředky svěřenými jim zaměstnavatelem a střežit a ochraňovat majetek zaměstnavatele před poškozením, ztrátou, zničením a zneužitím a nejednat v rozporu s oprávněnými zájmy zaměstnavatele." Porušení kterýhokoliv ustanovení §301 opravňuje zaměstnavatele e zrušení pracovního poměru podle §52 odst. 1.

Náhrada škody - § 250 odts. 1, § 252 (pokud mu byla svěřena data, třeba zaměstnanec IT, a podepsal to), § 257 odst. 1 a 3  a § 259, §261 odst. 3 zákona 262/2006 Sb. - a to při úmyslném jednání v plné výši i s náhradou ušlého zisku.

A ještě jsem nepracoval nikde, kde by se na vstupním školení neškolilo i zacházení s IT prostředky. Takže podpisem vstupního školení a pracovní smlouvy přestane být zkopírování zdrojáků nebo výkresů a jejich vynesení nedbalostí.

Proč bys chtěl vynášet data ze "čmoudu" od M$ nebo Google? Ti už přece ty data mají...
A "nasadit" někoho do firmy = kriminální čin -> soud -> klepeta.

Spis je otazka proti komu je vlastne chces chranit? Proti M$ ci Google? Jsou snad tvoji konkurenci?

Chránit se není potřeba proti nikomu konkrétnímu. Chrání se firma proti
1) ztrátě dat
2) zneužití dat
3) proti výpadkům činnosti firmy

Ad 1) Ke ztrátě dat může dojít tím, že se nějaký automat u provozovatele čmoudu rozhodne, že jsou data v rozporu s tím, co je ve smlouvě nebo v právě zveřejněných podmínkách, popř. se až po ztrátě dat zjistí, že čmoud nezálohoval, jak slíbil.
Ad 2) MiTM. Nebo třeba díra v API přístupná z veřejné IP pro několik firem (u standardního produktu),  která by ve firemní DMZ nebyla zneužitelná.
Ad 3) In-site je s rizikem výpadku dodávky energie, nebo poruchy železe (dá se odstranit hot / warm zálohou). Čmoud závisí na napájení firmy, konektivitě, DDoS na čmoud, plnění smlouvy poskytovatelem čmoudu, zablokováním přístupu k datům soudem po křivým obvinění... Netřeba připomínat, že bez dat nejede sklad materiálu, expedice, účetnictví, marketing,...

[PetrM]

No, v podání některých firem může znamenat cloud = desktop apka + předplatné

coz je zpravidla vyrazne levnejsi a efektivnejsi nez resit vlastni infrastrukturu...

Do chvíle, než se zjistí, že hyper výhodnou cenu ve smlouvě dosáhli tím, že nezálohují a jedou na bazarovým železe. A na potopeným SROčku se moc nezahojíš... :/ Nebo pokud neřeknou "Máme tvoje data, od prvního platíš pětinásobek, nebo je smažem."

----------------------

Paranoia je v našem oboru výhodou....

[donnie.tb]

Cloud je v podstate neco jako API. Pouzivas to a nestaras se jak je to implementovany.

Pouzivali jsme Amazon AWS s Elasticbeanstalk cca 3 roky (PaaS). Samozrejmosti je zalohovani do ruznych zon (napr. evropa a asie) pro pripad nejake prirodni katastrofy, ultra jednoduchy load balancing, warning zpravy temer na cokoliv (sms nebo email) co je AWS schopno merit (coz znamena nekolik tisic parametru od vytizenosti cpu po pocet I/O pristupu), deployment nove verze aplikace s minimalnimy vypadky, multi node prostredi (auto scaling) opet konfigurovatelene skrz nekolik tisic atributu (napr. vzroste cteni z disku a stoupne vytizenost cpu => prida jeden node a.k.a. EC2 stroj), moznost konfigurace pristupu na jednotlive prostredi (VPN, security zones, access control), snadna konfigurace DNS (pokud potrebujete), detailni monitoring DB, jendoduche vyuziti S3 uloziste pro ukladani (fakticky) neomezeneho mnozstvi souboru, CDN, posialni emailu (SES), nosql ulozisted, elasticsearch, etc ....

O tohle vsechno se muzes bud starat sam nebo to nechas na nekom jinem (treba ten amazon ) a jenom si nastavis svoji konfiguraci, bud skrz CLI pro nejake automatizovane procesy (napr. deploy nove verze) nebo i jen pres webove rozhrani pokud je to jednorazova zalezitost. Zaroven Amazon pridava kazdy mesic nove veci (napr. pro Machine learning, Lambda, ...) ktere potencionalne muzou jeste vice ulehcit procesum ktere potrebujes resit. Nestarate se o hardware o jeho vymenu nebo vypadky. Staras se primarne o svuj business.

Tohle je Amazon, nekdo kdo bude znat Azure muze pridat jine postrehy.

[Trident]

Drive se nahravala data a dokumenty na server. Ted je moderni nahravat data a dokumenty na cloud.
Potreboval bych poradit jaky je v tom rozdil.
Momentalne mam predstavu ze cloud = server + nejaka cool serverova aplikace neco jako samba s nejakym coool web pristupem a databazi. Tedy, ze je to v podstate stejne, jen se tomu jinak rika, aby se to prodalo.
Mylim se prilis?

Asi jsem uz starej, ale co cmoud prinesl jako plus pro nasi firmu.
1) Kdyz neni jeste hotovy datacentrum a buzinec se zblazni a krici: we want our service now!, je mozno okamzite deploynout servery
2) kdyz je nejaky projekt a pro developery neni volna kapacita a pokud nedelaji na necem pod rezimem prisne tajne tak je mozno jim dat zdroje na vyvoj hned

Co odnesl:
1) Musime zalohovat i nektera data v docasnem cmoudu na nasich datacentrech v pripade ze vy se cmoud rozmyslel a nefungoval - uz parkrat nas jeden megaposkytovatel odstrihnul kvuli jedne appce co mela simulovat utoky
2) Nemuzeme deployovat stare OS a technologie. Nelze deployovat vetsinou na nic jineho nez x86. Jine platformy jsou hostovane jako standalone
3) I mala pobocka musi mit kvuli vsemu v cloudu aspon zdvojene pripojeni oproti minulemu stavu kdy byl mozny i offline sync ze serveru na pobocce. Ne vsude je to uplne jednoduche. Napr kvuli pamatkarum a nepovoleni dalsiho MW spoje a vykopu na optiku se musela stehovat pobocka v Brne do drazsi budovy - dalsi vicenaklady.
4) Cmoud se obcas rozhodne ze chcipne servisu ale na jejich internim monitoringu to nejde videt. Takze mame dalsi monitoring:(
5) Reseni problemu je zdlouhave protoze cmoudi maji dalsi subdodavatele a nez se to probubla tak i jako velky zakaznik cekame i pul dne.
6) Uz neexistuje jednoducha rovnice poridim hw, takova spotreba, takove chlazeni,takovy servis, tolik mista, tolik dratu/vlaken, takove TCO a hotovo(zbytek resi financni). U cmoudu je tisice polozek a platime si extra firmu ktera vybira co je vyhodne. Dost casto skoncime i u klasickych low cost( rozumej x86) dedikovanych serveru ktere po odepsani konci v testlabech.
7) Cmoud muze bezet v ruznych jurisdickcich ktere nemusi mit vas zakaznik rad. Ad absurdum hostovat treba yandex v amazonim cmoudu nekde v us:) A musite resit treba i statni spehovaci krabicky(treba Rusko), povinny tranzit pres statniho ISP, povinne spojovani zahranicnich hovoru pres statni telco firmu(Indie) vykaznictvi apod. Takze nemas jenom jednoho cmoud poskytovatele ale musis mit but mistniho nebo holt v te zemi stejne postavit datacentrum.
Cmoud vetsinou neresi minoritni hw platformy
9) Znovu pouziti licenci ktere jsi nakoupil muze byt problematicke nebo omezene. 
10) V momente kdy musis synchronizovat velke mnozstvi dat (napr. urychlovace, vedecky vyzkum, mapovani zeme, astronomie, ruzne vedeckotechnicke vypocty, analyza financnich toku, legalni spehovaci aktivity) zapocitava se zpozdeni mezi cmoudem a uzka datova hrdla mezinarodnich okruhu. Za ten okruh k cmoudovi si opet priplatis (jestli ho vubec nabizi a lze ho zakoncit v datacentru nekde v Ulanbataru...)
11) Nejistota vykonu. Ne vzdy je zcela jasne co a jaky vykon muzes od sluzby ocekavat.
12) Ruzne predstavy poskytovatele cmoudu o tvych sluzbach ktere na tve reseni nepasuji. Hostovat si u cmoudoveho poskytovatele SS7->IP ci mit tam virtualni ustrednu a TDM->IP nebyva idealni napad.