[Solved] Szerver - kliens infrastruktúra kialakítás + hálózat + megfigyelő rendszer

Debian GNU/Linux

Sziasztok!

Egy meglehetősen komplex feladatot kell elvégeznem, és a nálam tapasztaltabbak segítségét szeretném kérni.
Jó irányba szeretném elindítani a projektet és minden ötletet, tanácsot szívesen fogadok.

Feladat:
- Egy 20 PC-ből álló iroda kialakítása. Teljesen szabad kezem van a kialakításban - mind szerver OS + konfig, mind kliens választás, megfigyelő rendszer felállítása, stb. tekintetében .
- Az irodai kliensek bérelt vonalon fognak egy szerverhez kapcsolódni. --> Helyi szerver/szerverszoba nem lesz.
- VPN a szerver-kliensek között.
- A klienseket a könnyebb ellenőrizhetőség/korlátozások érdekében domainba kell léptetni.
- 1+1 szerver lesz beállítva (1 éles + 1 backup ha kiesik az egyik)
- A rendszernek bővíthetőnek kell lennie (földrajzilag több helyen fognak irodák nyílni, aminek szintén ehhez az architektúrához kell kapcsolódni)
- A klienseken a munkavállalók adatrögzítést/logisztikai műveleteket/számla kiállítást/ fognak végezni. Tehát nagyjából egy böngészőt fognak használni, egy számlázó programot és egy-két kisebb tool-t.
- A bizalmas adatokat, adatbázisokat, illetve a honlapot egy másik szerveren fogják tárolni. A felhőben, csak az UPDATE kommentben írt dolgok fognak futni (esetleg egy belső NAS-on ami naponta ment a szerverre)
- Cisco router/SW lesz használva illeve Ubiquity access point. <-- NEM kötelező
- Hardveres tűzfalat betegyek-e? (A szerver után lenne célszerű elhelyezni, de ha datacenterben vagyok, azt hiszem ezzel nem kel foglalkoznom :))
- Az iroda nagyjából 250-300 m^2 alapterületű
- A szerveren csak egy AD fog futni ill a LAN management-jéhez szükséges szoftverek. (DHCP, DNS, DC, levelezés, netfilter esetleg app. tűzfal)

A kérdéseim:
- Milyen szerver OS-t választanátok a feladathoz? (Linux vagy Windows?) --> Én Debian Linux + Samba 4 (Domain Controllernek, viszont nem tudom, hogy több száz kliens gép esetében lesz-e ez olyan stabil mint a Windows-os AD, ill. minden szolgáltatást amire szükségem lesz megtalálok a Linux oldalon.)
- Ha linux szervert választok, hogyan oldhatom meg a primary-slave szerver üzemmódot. Milyen technológiát kellene használnom, hogy a slave szerver átvegye a helyét a masternek ha az kiesik?
- Mindezeket úgy, hogy a két szerver nem feltétlenül van ugyanabban a datacenterben.
- A szerver bérelve lesz, nem saját. --> Az adatok sertetlensége/integritása ebben az esetben garantált? Elhihetem a datacenternek, hogy nem nézegetik a belső levelezést/adataimat?
- A kliensek-nek Windows 8.1 vagy W10-et gondoltam, ahol Windows szerver esetében GPO-kkal erősen le lennének a userek korlátozva (Linuxnál van erre alternatíva? --> ilyet még nem csináltam)
- Milyen megfigyelő rendszert javasoltok? (Helyben rögzíteni, amit naponta mentenék a szerverre 1 hétre visszamenőleg)

Előre is köszönöm a sok segítséget.
UI: A feladatot többen is fogjuk csinálni, de tudnom kell, hogy hogyan építsük fel az egészet az alapoktól ill. milyen technológiát használjunk.

UPDATE: http://hup.hu/node/147155#comment-1986212
Kiderítettem a pontos kliens oldali igényeket:
- Az alkalmazottak csak adminisztrációs/számlázást/logisztikai feladatokat illetve az ügyfelek kiszolgálásával kapcsolatos feladatokat fognak ellátni az irodában - webshop miatt. (Mindezt böngészőn keresztül egy weboldalon, illetve később egy Windows-os külső fejlesztésű tool-al)
- Nyomtató/scan/fax - nagy teljesítményű hálózati printerre is szükség van a számlák nyomtatása miatt. (még nem választottam típust)
- A számlázó programot a webfejlesztő cég írja
- Belső levelezés

- Szükség van tehát böngészőre (Chrome), Office (Office 365 - Office 365 Vállalati Prémium verzió), Adobe Reader, Vírusírtó (ESET NOD32), Java szoftverekre a kliens gépeken. (Windows 7 vagy Windows 8.1 - mely a fizikai hardverrel lesz megvásárolva)
- Az Office 365 license által nyújtott Exchange szolgáltatás lesz használva a belső levelezésre.

# Hardver: PC-k lesznek: Dell Optiplex 3020 + Dell U2414H + Micro Dual VESA Mount
- Illetve lesz két nagyobb UHD-s monitor ahol reklámok/vásárlási statisztikai adatok jelennek meg
- Minden gép UPS-en. (Még nem választottam, de APC-n gondolkodom)
- Azt hiszem nem szükséges egy nagy UPS-t beszerelni és kiépíteni szünetmentes aljzatokat minden box-hoz.

# A tűzjelző/Behatolás jelző rendszereket egy külső cég csinálja
# Szintén szükség lesz beléptető rendszerre és kapukra, melyet szintén egy külső cég vállal el.
# Az elektromos hálózat átvizsgálását/megerősítését ha szükséges szintén egy külső cég végzi (UPS-ek is lesznek, ill ha kell új szerződés lesz kötve az EON-nal)

# Az én feladatom a következő:
1. szerver-kliens infra tervezése/konfigurálása/karbantartása (Windows Server 2012 R2 mellett döntöttem mint szerver OS)
2. hálózat megtervezése/konfigurálása
- a kábelezésre is megvan már az alvállalkozó
3. kliensek karbantartása/telepítése/konfigurálása
4. kamera rendszer beállítása

Jelenleg itt tartok:

- Szerver szoba nem lesz, csak egy kis "zug" ahol egy rack szekrényben fog ketyegni a router, switch, UPS, illetve egy belső szerver amire a kamerák fognak rögzíteni.
- Ez a kis terem szintén zárható lesz ill. klimatizált, és megfelelt a tűzvédelmi/biztonsági előírásoknak. Valóban kicsi helyet kell elképzelni, ahova egy kb 10-15U magas rack befér, ill. egy torony szerver.
- A kamera nem felhőbe rögzít, csak helyileg. A felvételek nézegetése szintén távolról történik, ill. live a főnöki irodában.
- A felvételek 1-2 hétig lesznek tárolva, és ha kell felhőbe mentve - hétvégén.

- Windows Server 2012 R2: AD+DNS+DHCP+Remote Desktop+BitLocker+FileServer+IPSEC+sok GPO.
- Felhőben, titkosítva minden.
- A levelezés backupja a MS feladata.
- A printer management nem szükséges.

- Internet kapcsolat: Bérelt vonal 50/50 vagy 100/100. Plusz egy nem szimmetrikus 100Mbit/s-os backup vonal.

- A hálózati eszközök tekintetében pedig elbizonytalanítottatok. Itt most nem tudok dönteni.
Sokat gondolkoztam a jelenlegi helyzeten és lehetséges, hogy túlzásba viszem a CISCO-val és természetesen mással is meg lehet valósítani a "szekuritit", olcsóbban, jobban. De ezek a megoldások egyelőre nem ismertek a számomra.

Üdv.:
V007

  • 16131 megtekintés

( golgota | 2016. 04. 27., sze – 16:49 )

Minek gondolkodsz Lnuxban, ha a windowst ismered. Egyertelmu a leirasodbol, hogy azzal jarnal jobban.
Ne eroltesd a Linuxot szerintem ebben az esetben.
Termeszetesen minden szolgaltatast megtalalsz a Linux oldalon is amire szukseged van es szepen mukodnek a HA megoldasok is. De a leirasodbol nekem egyertelmu, hogy a wint valaszd.

Amugy en elore gondolkodva alapvetoen AWS-ben hoznam letre a szervert es kesz. Ott mindenre megvan a szolgaltatas es alapbol redundans. Es a kesobbiekben a geolokaciok bekothetok.

Amennyiben idáig windows-os gyakorlatod van, ne kezdj bele egy ilyen mérvű konkrét projektbe linux-al, ha csak nem rendelkezel a megvalósításra korlátlan idővel. Kezdésként soxor be fogsz akadni (ez teljesen normális), különösen a HA kialakításnál és még nem beszéltünk ennek üzemeltetéséről, hibajavításokról. Üzleti szempontból inkább a kész, eladható, általad begyakorlott megoldások választását javaslom. Mindemellett az általad írtak linuxos megvalósítását párhuzamosan javaslom. Egy nagyon jó ismerkedés, és gyakorlási lehetőség, mindenféle szükséges leírást meg fogsz találni hozzá a neten (elég nagy anyagot fed le). Természetesen ezt úgy írom, hogy nem tudom milyen szintű linux ismereteid vannak, csak az általad írtakra támaszkodok!

Csak egy otlet AWS-re:
Directory service - Active Directory - HA alapbol megvan azert nem faj a fejed
S3/Glacier - Backupra - a Glacier lassu es draga visszatolteni de archivalasra, hosszu tavu nem hot-restore dolgokra olcso
Csinalhatsz kulon VPC- Virtual Private Cloud - mintha sajat datacentered lenne
Felhuzol egy Elastic Load Balancert - moge beteszel ket gepet - kesz a HA - nem faj a fejed az IP cim miatt
Route 53 - DNS
RDS - Adatbazis - kezeles - ez is alapbol HA-s
Cloudwatch monitoring
En nekem meg az otthoni Unifi-m kontrollere is onnan fut - ajanlanam neked is...

Az egeszet egyszeruen API-n keresztul vagy weben keresztul kezeled - es jogosultsagokat oszthatsz kulonfele szolgaltatasokhoz...

A VOIP-ho ez nem futtatnek 1-2 Linux servert Egy Amazon Loadbalancer mogott es FreePBX-el. A freePBX managelese egyszeru webes feluletu es onnan tovabb hardware VOIP vagy softphone-ok barmik lehetnek... A freepbx integralhato a mar letezo AD-vel is...

Bevallom őszintén ezzel megnyugtattál valamelyest :)
Én is túl paranoiás típus vagyok, ennek ellenére a héten történt konzultációk egy része szintén igazat ad neked és javasolják a Cloud használatát.
Aztán ha a cég túlnövi magát érdemesebb +5 év múlva saját szerverparkot kialakítani.

Egyelőre pedig a Cloud nyerő lesz.
Egyelőre 3-an vannak a kosaramban:
- Azure
- AWS
- Aruba (Velük kedden beszélek)

Az, hogy egy vagy több cég mit csinál (legyen bármekkora), még nem garancia arra, hogy "helyesen" cselekszik, illetve hogy a felhő mindenkinek mindenre jó és vakon követni kell:
- milyen szolgáltatást használ?
- miként használja?
- mire használja?
Ha már így előhozod ezeket a "referenciákat", tudnál bővebbet/konkrétabbat is? Említésük így lenne teljesen kerek, anélkül elég nehéz eldönteni, hogy egy másik cégnek (akár magyar, akár angol) megfelelnek-e az általuk igénybe vett szolgáltatások. (például olyan szolgáltatást is igénybe vehetnek, amihez a témabeli cég túl kicsi, ilyenre is láttunk már példát)

Engem meglepne, ha AWS-ben nyíltan tárolnának vízum adatokat. Ha ez mégis így van, nem feltétlenül helyénvaló és követendő példa, de ehhez nyilván ismerni kellene a jogi környezetet (ami kérdés, hogy kellően józan-e, bár ez nyilván mellékes szempont).
Egyszerű szemléltetés: ha például egy pénzügyi szervezetnek van egy saját tárolója, gyártónak sem küldhetnek vissza hibás lemezeket, amennyiben nem titkosítottak rajta az adatok. Ehhez képest egy külső szolgáltató legalább 2x-es kockázatot jelenthet. Úgy gondolom, a vízumadatok sem kevésbé érzékenyek.

Ezzel nem azt akarom mondani, hogy jelen projekt keretében nincs helye "felhő" szolgáltatásoknak (például jellegtől függően a weboldalt jó eséllyel egyszerűbb kihelyezni külső szolgáltatóhoz), mindössze azt, hogy tisztában kell lenni a követelményekkel és a megvalósítás jellemzőivel.

A dolog ennel bonyolultabb - Erzekenyebb adatok (meg) tenyleg nem az AWS-en vannak - de ugyanugy felhoben. A Skyscape ugyan eszmeletlen draga cserebe viszont egy darab F. talicska es nincs nap hogy ne lenne vele gond es kb olyan stabil mint Jozsi bacsi ejszaka 1 ora korul a kocsmabol hazafele... Viszont "CERTIFIED" :) a fenti tenyekre masok is rajottek es most migralgatunk AWS-re persze ha a certified politikai/jogi bohockodas megoldodik es ahogy oldodik meg... ( egyebkent ki mondta hogy _nyiltan_ vannak tarolva az adatok )

Tudom hogy nem mindenre jo a Cloud de ha jobban belegondolsz mi a nagy sok kulonbseg a sajat szerver es a cloud kozott - a sajat vasat a ceg Ultratitkos szervertermebe teszed ahol a ceg Galaxy riasztoja vedi vagy egy hosting centerben csucsul ahol manapsag mar jobb helyekre csak elore egyeztetett idopontal es retinascannerrel mesz be - de meg akkor sem kell (kb 6 eve voltam utoljara DC-ben es tobb cuccot uzemeltetek mint akkoriban)... Melyik a biztosabb? Ha meg adatcenterbe rakod Kb ugyanott vagy mindha cloudba lenne - OK ertem en hogy a virtualis konzolhoz mar a cloud operator is hozzaferhet (elmeletileg) - ha a cucc fel van bootolva de ugyanez lehet ervenyes a sajat cuccra is pl ILOM-on keresztul. Amit halora dugsz az potencialisan elerheto a fizikai biztonsag pedig asszem jobb helyen vagy egy nagy cloud szolgaltatonal vagy datacenterben mint a sajat telephelyen... Ha pedig annyira fontosak es titkosak azok az adatok barmilyen cloud szerverre tehetsz encrypted FS-t 'oszt joszel...

A tenylegesen elerheto dolgok (belepteto rendszer helyi gyors DB es a jogilag szabalyozott policy dolgokat stb.) kiveve nem igazan latom realis okat amiert felni kellene a cloud-os megoldastol. Es mindenre van megoldas - hasznalj titkositast... A "sokbites titkositasst is feltorik es elolvassak", "a szolgaltato hasznal valami gyanus DOM0-t", ellen pedig mar csak a thinfoil hat ved meg igazan.... Ilyen a vilag, ebben elunk. A jol eldugom otthon sosem talaljak meg csak hamis biztonsagi erzetet ad IMHO... Es az elonyok nagyon-nagyon megkonnyitik a napi eletet ha a dontes megszuletett es az implementacio jol van megcsinalva - de ez utobbi igaz mindenre...

A fentiekkel nem azt akartam mondani, hogy nincs letjogosultsaga a sajat park fenntartasanak, de manapsag meg azt is inkabb virtualizalva erdemesebb es innen tovabb pedig aztan kinek a pap es kinek a papne... Veszed vagy bereled ? Uzemelteted is vagy csak hasznalod... A legvegen ugyis minden ut Romaba vezet es csak annyira lesz biztonsagos amennyire hozzaertoen van megcsinalva.

Tényleg nem írtad, hogy nyíltan vannak az adatok, de azt sem, hogy titkosítva. Ezen lényeges információ nélkül úgy értelmezendő az állítás, hogy az AWS úgy jó a Home Office-nak, ahogy van (adatkezelést beleértve), ezen kézenfekvő értelmezés kapcsán bátorkodtam megjegyzést tenni.

Sok mindennel egyetértek, de nem mindennel. A biztonság csak egy szempont, titkosítás sem old meg mindent.

"nem igazan latom realis okat amiert felni kellene a cloud-os megoldastol." - azért, mert az ember nem szeret olyanba belefutni, mint Ti a Skyscape esetén. És akkor ez egy enyhe eset, lehetne durvább is: egyszercsak megszűnik a szolgáltatás, hol kopogtatsz az adatokért? Vagy műszaki hiba miatt adatmegsemmisülés.

Az nem érv, hogy a nagyok nem hibáznak. Mindenki hibázik, a nagyok tudnak igazán nagyot hibázni. Nem mintha már nagyon öreg róka lennék, de IT-ben tevékenykedve jónéhány évet láttam már annyi és olyan dolgot, hogy alapból szkeptikus vagyok (nemcsak "sufni" helyeken, sőt...). A felhő esetén az a gond, hogy nem fogod pontosan megtudni a határokat, arra kell készülni, hogy egyszercsak nincs (Microsoft, Google, Amazon, ... esetén ennek nyilván nem nagy az esélye, de azért láttunk már lufikat; elég, ha pont a Te adataidat éri kár egy "technological limitation"-ből kifolyólag).

"hosting center": röviden vannak olyanok, ahol szép molinó takarja el a szemétdombot. Nem mindenkinek van "hosting center"-re igénye, vacakra előfizetni (leginkább csak hinni lehet valamiről, hogy jó) pedig nem feltétlenül jobb, mint a sarokba berakni egy szervert (és megfelelő mentésről stb gondoskodni, nem feltétlenül kerül horror pénzbe). Ha valaki strucc politikával épít szerverszobát, az megérdemli, másik eset.

Összességében nekem az a véleményem, hogy vannak (nem mindenki), akik a felhő vonatra azelőtt szállnak fel, hogy tudnák hova megy és mennyiért, megelégednek annyival, hogy tetszik a színe. Általad leírtak alapján a Home Office is kicsit ilyesmi a Skyscape-pel.

Általánosan jó megoldás nincs, mindenkinek el kell döntenie, milyen megoldásokat alkalmaz: lehet egyiket, másikat, de vegyíteni is. Csak pontosan tudni kell, mit, miért és hogyan. Valóban: hozzáértés szükséges, de ez sokszor hiányzik. Mind technológiai, mind üzleti szinten, ráadásul a kettőt össze is kell kapcsolni.

Es mindenre van megoldas - hasznalj titkositast...

Ezt meglehetősen nehéz kivitelezni pl. egy levelezőszervernél (gyk: a feladat, hogy clear text formában nem fordulhat meg az adat olyan gépen, amelyikhez fizikailag más hozzá tud férni). De alkalmazást sem lehet így használni felhőben, hiszen az alkalmazás sem láthatná a clear text adatokat. Szóval a titkosítás nem oldja meg a lényegi problémát, amennyiben a szolgáltatás nem kb. a data storage szintjén mozog (dropbox meg hasonlók).

Ha meg adatcenterbe rakod Kb ugyanott vagy mindha cloudba lenne

Nem, mert egy data centernél el lehet értelmesen fizikailag zárni a szervereket. Cloud esetén ez fogalmilag kizárt.

Clear text alkalmazas...
Ezt nem egeszen ertem - legyen az adat titkositva a serveren, es kommunikalj vele titkositott csatornan... Meg a kliens/server is mukodhet _elmeletben_ encrypted modban es a legvegso ponton - ha feldobod a keprnyore az adatot kell csak alkalmazni a kulcsot... Email... Hat igen varra vannak a belso policy-k amik kimondjak hogy emailben erzekeny adatot nem osztunk meg... Milyen erdekes hogy egyesek azt allitajk az erzekeny adatok otthon ulnek es csak az email van a felhoben. Te pedig kimondottan peldakent emlited az emialt mint ami nem titkos... Mondjuk mar erre is vannak megoldasok mint tudjuk...

Nem, mert egy data centernél el lehet értelmesen fizikailag zárni a szervereket. Cloud esetén ez fogalmilag kizárt.

Szerintem hamarabb lehet a fizikailag elzart szerverhez ferni mint a majdhogynem logikailag letezo, georedundans VPC-ben csucsulo "instance" -hoz... No ahhoz ferj hozza fizikailag. Mint emlitettem ahhoz mar csak a virtual console marad, de pl AWS-nel nincs is olyasmi - ha van rajta SSH kulcsod ok, ha nem akkor joszel. A fizikai elzarasrol pedig: azok a vasak amik legalul zummognek - nos azok azok szerinted hol vannak?

Ismetlem, nem vagyok cloud imado evangelista es teljesen egyetertek azzal hogy mindket megkozelitesnek megvan a letjogosultsaga es a feladathoz kell az eszkozt valasztani, csak ugy gondolom, hogy nem kell feltetlenul elvetni egy a feladatra teljesen alkalmas megoldast pusztan azzal az indokkal hogy "cloud" meg fizikai megkozelithetoseg.

Ezt nem egeszen ertem - legyen az adat titkositva a serveren, es kommunikalj vele titkositott csatornan...

Az a logikai probléma, hogy ha az alkalmazás nem ismeri a kulcsot, akkor egészen kevés hasznos dologra használható (hiszen csak toszogatni tudja a titkosított adatokat a kliens felé, kb. mint egy dropbox), ha pedig ismeri, akkor semmi nem akadályozza meg a fizikai hozzáféréssel rendelkező üzemeltetőt, hogy egy VM-be dobja az egész gépet (ezt ugye távolról kurvára nem látja a gép bérlője), és a futó oprendszer memóriájából bármit kiszedjen (leginkább azt a kulcsot, amit az alkalmazás ismer, és amivel utána az egész szarhoz hozzá tud férni). Ha eleve VM-ben fut az egész, mert VPS-ről van szó, akkor még ennyit sem kell tennie, mert kapásból hozzáfér a VPS memóriájához, aki admin az alatta levő vason. Még csak fizikai hozzáférésre sincs szüksége...

Hat igen varra vannak a belso policy-k amik kimondjak hogy emailben erzekeny adatot nem osztunk meg... Milyen erdekes hogy egyesek azt allitajk az erzekeny adatok otthon ulnek es csak az email van a felhoben. Te pedig kimondottan peldakent emlited az emialt mint ami nem titkos...

Mármint kifelé. Még soha nem láttam olyan céget, ahol a belső levelezés ne lett volna telis-tele érzékeny belső adatokkal.
Sajnos a külső ügyfelek egyébként pont le szokták szarni a mi belső policy-jainkat, és gondolkodás nélkül beküldik az érzékeny adatokat tartalmazó ajánlatkéréseiket emailben. És a büdös életben nem veszed rá a jelentős részüket, hogy PGP-vel vagy S/MIME-mal küdjék a leveleiket... inkább keresnek másik céget, akivel nem ilyen "macerás" levelezni, hiszen nem az ügyfél van a szolgáltatóért, hanem fordítva. Illetve még az is lehet, hogy nekik nem is érzékeny adat az az egy ajánlatkérés, de a cég szempontjából nézve meg simán lehet a sok ügyféltől bejövő ajánlatkérések összessége masszívan érzékeny adat.

Ez a beszelgetes kezd nagyon elmenni elmeleti sikok fele... Tudok en az ugyvedje lenni es mivel bennunket IT-sokat azert fizetnek (kicsit altalanositva) hogy problemakat talaljunk es azokhoz megoldasokat szallitsunk, kello melysegig elmerulve nyilvanvalo hogy mindket oldalnak megvan az elonye es a hatranya is. Kisebb eselyt latok arra hogy valaki - elegge elszant es hozzaerto kell legyen a illeto - vegigvigye a feladatot hogy feltor egy tisztesseges felhot (itt nem a joskapista hosting BT VPS-t ertem - ambar meg az is lehet Joskapista tenyleg erti a dolgat es hobbibol a vilag legjobb whitehat biztonsagi szakertoje) elokeresi a Te "instance"-odat, clonozza, lemasolja a kulcsot es hasznalja... Ugyanugy be lehet elmeletben setalni egy DC-be - berelsz mellette egy gepet. kersz idopontot stb... Es utana a fizikai gepen init=/bin/bash aztan mar indulhat is a moka...
Mindent lehet csak eroforras, hozzaertes, elszantsag es akarat kell hozza...

A kotelezo https://xkcd.com/538/

De sokkal valoszinubb, hogy "social engineeringel" spoof emaillel, cross site scriptinggel, 0 day vulnerability stb mennek be es viszik a cuccot... Az elet eddig legalabbis ezt mutatja. Es itt mar nem a fizikai hozzaferes fog szamitani. Tapasztalatom szerint a fizikai vagy serial consol hozzaferes csak egy pont a biztonsag tervezesenel, es valos sajat adatcenter, VPS, vagy cloud esetere is megvannak a jobb vagy rosszabb, de sok esetben elegseges megoldasok...

Amit en allitok - a felho nem az ordogtol valo es eppen annyira lehet biztonsagossa vagy sebezhetove tenni mint a sajat uzemeltetesu vasakat, es ha az adott feladatra egybkent alkalmas akkor komolyan megfontolando a hasznalata mert szamtalan elonnyel jar...

Sorry, szakmai ártalom, tűzfalas cégnél dolgozom :) Ettől független nem ajánlom, max. ha jelentéktelen adatokról van szó, és keringhet a tartalom a neten az idők végezetéig :) Emlékszem amikor amikor sok-sok évvel ezelőtt meséltem a haveromnak amikor még gmail poweruser voltam :), "- Te valamiért ugyanolyan tartalmú reklámokat látok, mint amiről dumálunk itt mail-ben" "- Áááá hülyeséééég, miért olvasná bárki a te leveled, nem vagy te olyan nagy ember, hogy érdekes legyél bárkinek :)" Ebben mondjuk igaza volt, olvasni a kutya nem olvasta :)

Így van :) INGYENES . Nekem már semmi ;) Egyébként csak hoztam egy példát, ne kapaszkodj nagyon bele ;) csak javasoltam. Ez nem éppen egy security topic. A gugli nekem is a barátom, tárolja a tudásom, de a cégek nem megfelelő ( nem a hacker-ek, szolgálatok ellen, egyáltalán az alap megoldások) védelme miatt a lelkes gugli barátunk olyat is be-tag-gel, ami nem biztos, hogy a nyilvánosságra tartozik.

( pike.killer v | 2016. 04. 27., sze – 21:25 )

Amit nem lattam a leirasodban es erdemes vele fogalkozni:
1. nyomtatas
2. fax
3. telefon
4. internet szabalyzas
5. levelezes

Kovetkezok szamomra nem vilgos:
1. VPN a szerver-kliensek között. ( Minden egyes kliens vpn kapcsolatot epit ki vagy telephelyenkent lesz egy VPN)
2. Tehát nagyjából egy böngészőt fognak használni, egy számlázó programot és egy-két kisebb tool-t.( Mi a kisebb tool? Minden bongeszo alapu lesz? Nem lesz vastagklienses alkalmazas?)
3. Az irodai kliensek bérelt vonalon fognak egy szerverhez kapcsolódni. --> Helyi szerver/szerverszoba nem lesz. (MI ertesz beret vonalon L2, L3 kapcsolat? Telephelyen lesz internet kijarat? )

1: 1 hálózati nyomtató lesz irodánként (nagy teljesítményű)
2: Fax - még nem tudom
3: Cisco Call Center + 3-4 IP telefon. Első körben ez a terv, olcsóbb megoldást erre nem tudok.
4: internet szabályozás alatt mit értesz?
- netfilter (iptables?)
- Cisco ACL-ek?
5: Exchange vagy postfix, devcot, spamassian, stb. ha Linuxot választok.

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

1: Ez Irodánként max 20 kliens lesz. Ebben az esetben számít, hogy 1 VPN session épül ki, vagy 20?
2: 1-2 vastagkliens alkalmazás is lesz, a pontos szoftverlistát még nem sikerült begyűjtenem.
3: EZ még nincs eldöntve. Köszi, hogy felhívtad rá a figyelmem.

1. Lesz print szerver vagy direktbe veszed fel a nyomtatokat? Nyomatom managment kell?
3. CCX ( Cisco Unified Contact Center Express) nem egy olcso megoldas, foleg nem redundas kialakitasban es kell meg hozza CUCM (Cisco Unified Communications Manager). Es gondolom ha mar CCX akkor, hangrogzites is lesz.
4. Itt arra gondoltam , ha telephelyeken publikus internet van akkor ott is kell szabalyozni ki mit nezhet meg a neten. Viszont, ha minden forgalmat a DC ( DataCenter) fele iranyitasz, akkor csak ott kell korlatozni nagyobb DC iranyu vonali kihasznaltsagod lesz.

-----
1. Pl Ha a kliens epiti ki a VPN-t akkor úgy is tudja használni a rendszert, hogy nincs bent a telephelyen ez lehet elony es hatraby is.
2. Berelt vonal nagysaganak meghatarozasahoz meg jo lenne ezeket tudni. Pl elfordulhat egy streaming alkalmazas megeszi a tervezet vonalad nagy reszet.

1. Nem lesz print szerver. 10-20 gépmnél azt hiszem elég ha direktben felveszek egy hálózati printert.
3. - egyelőre kérdőjel
4. egy belső tűzfallal akarom szabályozni ki mit nézhet, ill milyen forgalom mehet ki a telephelyről. Így csökkentem a bérelt vonal terhelését is.
-----
1. Nem lesznek laptopok, otthonról senki sem léphet be. Tehát azt mondod ebben az esetben elég ha a router ill a server között egyszer kiépítem a VPN-t + IPsec-et és kész?

( djsmiley v | 2016. 04. 27., sze – 22:47 )

Szia!

Hát elég komplex a kérdésed, ritka h. ilyen thread-et nem trollkodnak szét h. "minek csinálod ha nem értesz hozzá" és stb :)
Samba4 jó lehet, ha Win license-en akarsz spóreszolni, Win 8.1-ig oké, ezt állíthatom, a 10-el voltak furaságok, de ment azért, csak van amin még reszelni kell sztem a sambaban.

A többire én így nem mondanék semmit, lehet majd becsatlakozom egy-egy szálba.

Megfigyelő rendszer: Ok, mennyi kamera, mi a büdzsé, hogy akarják nézni, stb.? Erre csípőből azt mondanám ha 16 kameráig bezárólag kell, akkor Axis Camera Companion. NVR nélkül tud központosítottan működni (vagyis olyasmi), íme: http://www.axis.com/sa/en/products/axis-camera-companion.

Üdv,
Zoli

Igen tudom, hogy nagyon komplex a feladat.
Van még egy bő félév, hogy elinduljon és szeretném átlátni a dolgot. Közben folyamatosan konzultálok szakemberekkel akik már foglalkoztak ilyen nagy és komplex projekttel. Szart nem akarok csinálni.

Köszi a kamera tippet, Axis-szal korábban már találkoztam és nagyon megbízhatóak voltak.

Az a bő fél év szűken elég, ha pontosan tudod, hogy milyen komponenseket, kitől, hogyan miként és miért, meg hogy lesz összerakva. A "de még kamera, meg még ez, meg még az..." a scope bővítését jelenti, amit jelen helyzetedben nagyon nem javaslok - vagy legyen (jól) priorizálva, hogy mi, mennyire fontos, és annak megfelelően belőve, hogy mikor lehet/szabad vele foglalkozni leghamarabb.

( nvik | 2016. 04. 27., sze – 23:18 )

nálunk ilyesmi rendszer van, s másoknak is üzemeltetünk ilyet!
ha érdekel, keress privátban!

( bognarattila | 2016. 04. 28., cs – 08:24 )

Itt nagyon sok még a kérdés, érzésre ellentmondások is (például NAS), amire a válaszok sokat alakíthatnak.

Mivel minden távol lesz, távoli bejelentkezéses (RDP vagy hasonló) rendszert sem vetnék el, főleg ha több irodát kell kialakítani a jövőben, hasonló módon. Így az irodába elég lenne vékony klienseket tenni, a felügyelet nagyon le tud egyszerűsödni (főleg több iroda esetén).

A NAS helyi funkciója nem világos, azok tipikusan nem magas rendelkezésre állású eszközök. Itt nemcsak a redundanciára gondolok, hanem arra is, hogyha elromlik, akkor nem feltétlenül van megjavítva 2-3 nap alatt. Két szerverrel a biztonsági mentést is meg lehet oldani, de a kérdés akár komplexebb is lehet annál, minthogy fájlokat kimásoltok valahova.

Kérdés az is, hogy a böngészős számlázó azt jelenti, hogy saját alkalmazás kiszolgáló fut (későbbi mondat ezt akár cáfolhatja is), vagy külső szolgáltatónál lesz használva. Levelezést is említesz, tehát saját felügyeletű szolgáltatás azért lesz.

Ha a szerver nem helyileg lesz, akkor nem biztos, hogy az a célszerű "LAN management"-hez (itt a "LAN" szerintem eléggé messze van a valós jelentésétől), illetve egy holnap inkompatibilis egy DC-vel (előbbi DMZ, másik belső hálózat).

A fentiekből kifolyólag (hálózati szegmentáció, többféle szolgáltatás) mindenképpen célszerű lenne virtualizálni is (fizikailag drága lenne).

Kicsit bonyolítja a dolgot, hogy több jövőbeli irodára is fel kell készülni, azaz a hálózatot annak megfelelően kell kialakítani.

" - Hardveres tűzfalat betegyek-e? (A szerver után lenne célszerű elhelyezni, de ha datacenterben vagyok, azt hiszem ezzel nem kel foglalkoznom :))" - attól, hogy adatközpontban vagy, a Te adataid nem lesznek jobban védettek, semmilyen irányban. Attól, hogy ilyen helyen fut a szerver (vagy akár VM-ek), pont úgy kell védeni, mintha a telephelyen futna a szerver szobában. Esetleg ilyen-olyan minimális védelmet kapsz, de ezt vagy tisztázni kell, vagy nem építeni rá.

"A szerver bérelve lesz, nem saját. --> Az adatok sertetlensége/integritása" - kérdés, hogy milyen a cég érzékenysége, miként van kezelve a szerver, például hibás merevlemez stb. Ha para van, akkor titkosítani is lehet operációs rendszeren belül, de ennek vannak különféle következményei, amivel nem árt tisztában lenni. Jellemzően ehhez is egészében kell látni az infrastruktúrát és az üzemeltetési folyamatokat, akkor lehet pontosan mérlegelni.

Arra figyelj oda, hogy itt sok tippet kaphatsz, de ha nem látod át 100%-osan a projektet (kérlek ne vedd rossz néven, de nem látod át), akkor nagy katyvasz lesz belőle. Célszerű lenne valaki olyat bevonni, akinek rálátása van az alap infrastruktúra megoldásokra (hálózat mindenféle vonatkozásban, operációs rendszerek, virtualizáció, mentések, ..., ...).

Arra figyelj oda, hogy itt sok tippet kaphatsz, de ha nem látod át 100%-osan a projektet (kérlek ne vedd rossz néven, de nem látod át), akkor nagy katyvasz lesz belőle. Célszerű lenne valaki olyat bevonni, akinek rálátása van az alap infrastruktúra megoldásokra (hálózat mindenféle vonatkozásban, operációs rendszerek, virtualizáció, mentések, ..., ...).

Tényleg nagyon pozitívan fogadom a tanácsaidat, nem veszek rossz néven. Tisztában vagyok vele, hogy nagyon sok negatívat fogok kapni a témában. Tanulni akarok és megvalósítani a projektet, viszont nem az ügyfél kárán.
Be fogok vonni mindenkit akit csak szükséges, hogy ez működjön.

Ha 6 hónapod van, akkor nagyon bele kell húzni, mert nagyon kevés.

Ha valamit rendelni kell, akkor 1 hónap számolandó, utána konfigurálni, tesztelni, betanítani, dokumentálni stb akár 2 hónap is lehet, tehát jó esetben van 3 hónapod megtervezni (sok gondolkodás és egyeztetés, dokumentálás), ajánlatokat kell kérni, pénzügyileg jóváhagyatni. Mivel nincs tapasztalatod, ezért esélyes, hogy a tervezésre rendelésig még egy kört kell számolni, akár nulláról. És akkor előzetes tesztekről nem is beszéltünk, amiknek simán lehet 2-3 hét az átfutásuk.
És gondolom nem csak ezzel foglalkozol napi 8 órában 6 hónapon át.

( rts | 2016. 04. 28., cs – 08:49 )

Ez egy baromi nagy projekt, sok pénz, (sőt kb. úgy látom, hogy korlátlan pénz) baromi sok szempont. Töredékét se írtad le a döntésekhez szükséges információknak, csak egyre nagyobb káoszt generálsz.
Itt majd jönnek osztani az észt összevissza sokan (:-)) de neked nincs se tapasztalatod, se kompetenciád hasonló projektekben (bocs, ez látszik. a némi szerveres tudásod ide nem elég). Ha a helyedben lennék, én felvenném a kapcsolatot egy tanácsadó céggel vagy megfelelően tapasztalt személlyel. (úgyse fogod megtenni, mert "te majd megoldod" de meg is fogod bánni majd később :-))

Igen valóban nagy projekt, még alig fogom fel mi a feladat, azért is hagytam ki rengeteg szempontot.
AZ egómat leadom és segítséget kérek a feladat megvalósításában tudom, hogy nagy falat, de van még idő és kihazsnálom, hogy átlássam az infrastruktúrát amit lényegében nekem kell kialakítani a semmiből.

Az az ido nagyon gyorsan el tud fogyni am :D

Szedd ossze az osszes alkalmazast es listazd ki hogy mi szukseges az uzemeltetesukhoz mert lehetnek olyan megoldasok amik elsore jonak tunnek aztan mikor beroffented a klienseket (ki van epitve hozza szerveroldalon minden) majd jon a fejvakaras hogy ez sem megy az sem megy illetve eppen megy de 0 esely upgradre/valtoztatasra vagy el kell hoza kolteni egy kalap penzt megint.

Úgy gondolom, hogy egy erős hálózat az alapja mindennek, s ezt CISCO-val a legcélszerűbb megvalósítani.
A HP eszközök ugyan olcsóbbak, de még nem konfiguráltam őket.

Biztosan van egyéb alternatíva. A SOHO eszközöket komolytalannak tartom egy céghez, annak ellenére, hogy viszonylag kevés kliens van.

Esetleg Ubiquity VAGY MicroTik eszközöket tudok még elképzelni.

Lassan összeáll milyen szolgáltatások lesznek, sikerült kiderítenem az igényeket is. Hamarosan Update-elem a topicot és tudok pontosítani az eddig elhangzott kérdések/tippek/ötletek alapján.

Nekem az egész projektről nem az enterspájz jutott az eszembe. Főleg hogy KKV szektor. Kis irodák, pár géppel...szerintem annyira felesleges ilyen eszközökben gondolkozni! Tiszta pénzkidobás.
Az más kérdés ha valaki csak cisco-hoz ért. Vagy megtanul mást (ami cisco után nem lehet nagy feladat), vagy nem neki való a project ezen része és kér külsős segítséget. (Direkt nem írtam hogy nem kéne neki, meg hasonlók...mert olyan körvonalakban rajzolódnak összegek hogy egy-egy alvállalkozó megfizetése csak "ebédpénz" az egészhez képest...)

+1

Arról nem beszélve, hogy Cisco és UBNT/Mikrotik egymás alternatívájaként meglehetősen komolytalan. Kicsit olyan, mintha azt állítanánk, hogy 7-es BMW mellett a Skoda Octavia vehető autó számba, a többi felejtős. (ráadásul hálózati eszközök esetén arányaiban sokkal nagyobb árkülönbség is lehet)

Aki 7-es BMW-ben gondolkodik, az nem fog Skodát venni. Aki Skodában gondolkodik, felhúzza a szemöldökét, ha 7-es BMW-t akarnának neki eladni. Autóról nagyjából mindenki tudja, hogy micsoda (BMW 7 akár ház ára), de egy hálózati eszközről nem feltétlenül tudja, hogy azért a pénzért még mi mindent meg lehetne oldani.

Kérdés, hogy cégautóként beszerezve melyik fér bele a büdzsébe, illetve hogy aki az autót kapja használatra, az mennyiben dönthet annak típusáról/felszereltségéről és ezzel az áráról. De ahol "flancológiai" szempontból is elég a Octavia (és lehet mellé venni egy másik szaladozós autót is a BMW árából), ott a bömös durva pazarlás.

Kasszakulcsot birtokló vezetővel beszéltél már pénzről? (vagy bárkivel, akinek legalább áttételesen köze van a pénzhez/döntéshez)

Cisco alatt három szintet is lehet érteni, gyanítom, Te a középsőre gondolsz, de a helyzet az, hogy ennél jelentősen nagyobb felhasználószámnál sem feltétlenül fizetik meg. Ráadásul meghibásodásra is kell forgatókönyv.

Az oké, hogy leírod a javaslatodat, "erős hálózat alapja" stb, de ha máshonnan is kérnek be árat, jó eséllyel lesznek jelentősen kedvezőbb áru alternatívák, amiket nem feltétlenül fogsz tudni megtorpedózni. 1-2-3 ilyen kérdéskörrel veszik a bizalom, vele együtt a projekt.

(az már viszonylag mellékes, hogy 20 felhasználó esetén nem igazán lehet "hálózatról" beszélni: 2 switchnél többre nagyon jó eséllyel nincs szükség, ebben az infrastruktúrában a switch típusa kb harmadlagos kérdés)

( xclusiv v | 2016. 04. 28., cs – 15:19 )

"- Az irodai kliensek bérelt vonalon fognak egy szerverhez kapcsolódni. --> Helyi szerver/szerverszoba nem lesz."

Ez esetben backup kapcsolat is legyen, más nagy szolgáltatótól. (Hallottam már olyat, hogy elment a "jóskapista kft" által biztosított backup vonal is elment amikor a fő matáv vonal, mert ők is matávon forgalmaztak.)
Erre is időt kell szánni, láttam már olyat hogy többszáz napos határidővel vállalta egy nagyobb netkapcsolat kiépítését a szolgáltató.

Az irodánál az elektromos hálózat minősége is fontos, azt is át kell nézetni villanyszerelővel a kismegszakítótól kezdve. Ha a betápot bővíteni kell, akkor az áramszolgáltatóval kell majd küzdened. Érdemes lehet a túlfeszvédelmet már a kismegszakítónál megoldani szerintem.

A 220 és LAN kábelezést egy hozzáértő céggel csináltasd meg, több cégtől ajánlat, stb. A 20 gépre szerintem 60-80 végpontot ki kell majd építeni, mert lehet hogy X ide költözik, Y-nak kell egy nyomtató, elromlik a kábel a falban, stb. Nem kell mindet switch-be kötni, legyen kifejtve aztán majd azt kötöd be amit kell.

A router, switch, kamerás vackok, elé mindenképp javaslok egy UPS-t, illetve ez legyen egy zárt fali kis rack szekrényben elhelyezve.
A router és a switch SPOF, ha bármelyik megáll akkor az iroda is megáll. Ha megoldható akkor legyen redundáns vagy hidegtartalék.

Kliensből én sok éves NBD garral vennék bármit is, ha bármi megdől akkor másnap(*) jönnek és javítják. Ha egységsugarú a munka és fontos hogy ne legyen kiesés, akkor érdemes lehet +1 gépet venni, azt is bekonfigolni és hidegtartalékként letenni. Ha egy PC ledől akkor Mancika átül a tartalék géphez, bekapcsolja és folytatja a munkát.

Ha minden kliensed azonos típusú (vagy legalább minden desktop és minden noti) akkor ahhoz egy OS image kell azonos driver-ekkel, szóval azt vegyél, ebből lehetőleg ne engedj.

Kliens és server oldalon is fontos lehet a backup, ezzel is törődni kell.

Ha iroda alatt nem csak az IT infra a feladatod, hanem bútortól a padlószőnyegen át az elrendezésig minden nyavalya is, akkor azt a részt próbáld meg lehetőleg lepasszolni valakinek. :) Lehetőleg olyannak, aki ott fog dolgozni, preferáltan olyannak aki ott főnök vagy hangadó lesz. Persze ha a te felelősséged akkor az ő munkáját is ellenőrizned kell...

Ha fél éved van akkor tervezz úgy, hogy menetrend szerint 5 hónap alatt kész legyen minden. Valami úgyis csúszni fog, és valszeg nem csak 1 valami, így legalább lesz némi mozgástered.

Ennek örülök.
Az elektromos részt nagyon sokan hajlamosak úgy venni, hogy az van, készen van, tehát jó. Ebből már otthon is lehetnek komolyabb szívások, de egy irodában :)
Amikor minden konnektor egy fázison van (15 A), aztán erre rákerül pártucat pc, nyomtató, kávéfőző, mikró, bojler, "szerver", és persze már alapban csúszott az indulás és minden órában nő a kötbér - na az megfizethetetlen. Minden másra ott a Mastercard.

Több helyen megy backup vonalként 3G/4G mobilnet - persze az a kérdés, hogy mekkora forgalomra kell méretezni.
Egyébiránt a "más nagy szolgáltató" sem 100%: volt olyan a világtörténelemben, hogy 2x2Mbit-es mikrohullámú kapcsolat egyik ágát kapta az üf. a másikat meg egy másik "nagy szolgáltató" bérelte. Aztán amikor a mikrót karban kellett tartani, akkor a t. ügyfél nézett ki a fejéből, hogy a másik szolgáltatótól vásárolt tartalék útvonal is ugyanakkor fog megállni, mint az elsődleges. De olyan is volt, hogy a (cégnek saját magától redundánsnak kért) 2x64kbit-es bérelt vonal egy érpáron érkezett meg a rendezőbe...

( coco | 2016. 04. 28., cs – 19:08 )

Ha én most csinálnék hasonlót akkor O365 meg Azure AD Connectet nézegetnék. Ha nincs különösebb security requirement mindent tolnék a cloudba.

A cég kritikus adatai miatt nagyon tartok a cloud-tol. Futok még egy kört egy saját mini szerver park kialakításában. És több iroda esetén is össze lehet így őket kötni, talán biztonságosabban.
Illetve a szerver bérlés/cloud használat 1-2 év múlva visszahozza a saját vas/szerver szoba árát is.

"Futok még egy kört egy saját mini szerver park kialakításában" - egy saját mini szerverpark nagyon alsó hangon indul ~1m-től, de akár 20m-ből is lehet "mini" parkot csinálni.

Az ismert, hogy mekkora a költségkeret és mik a valós üzleti követelmények (RPO, RTO különféle szolgáltatások vonatkozásában, valós adatbiztonsági igények, ...)? Az igény és a költség egymással szembe lett állítva? Amíg ezek nincsenek meg, teljesen mindegy, hogy milyen Wifi AP lesz, mert nem kizárt, hogy egy Unifi sem fog beleférni (bár ez még jó eséllyel átverhető legrosszabb esetben is, ha a vezető azt érzékeli, hogy sem a gépe, sem a telefonja nem tud wifizni egy vacak megoldással).

Minden cégnek minden adat nagyon kritikus egészen addig, amíg nem látják a költségeket. Hasonló vonatkozik a rendelkezésre állásra. Persze van cég, amely hajlandó költeni (jó értelemben), de nagyon sok cég esetén az informatika mint pénznyelő van elkönyvelve és nem látják át, mekkora kockázatot jelent egy alulfinanszírozott rendszer (persze sokaknak mázlija van, csak kérdés, meddig), illetve az sem egyedi példa, hogy a látszólag olcsóbb megoldás végül drágább lesz a mindenféle hegesztéssel és utólagos pótlással.

"Illetve a szerver bérlés/cloud használat 1-2 év múlva visszahozza a saját vas/szerver szoba árát is."

Hát számomra nem kérdés hogy a cloud olcsóbb. Hozzávetted az üzemeltetési költségeket, office csomag árát (már ha nem LibreOfficet akarsz használni), licenszek árát, szoftverkövetést, a vasak support költségét? Mindig a legfrissebb verzión vagy, nem kell vesződni a frissitésekkel. Több irodát szintén össze lehet kötni biztonságosan ha cloudod van, itt nem igazán látom a különbséget.

Alap infrastruktúrát, identity management (AD), levelezést, sharepoint, fileshare, egységes kommunikációt (VoIP/UC) biztosan nem üzemeltetnék, mert egyszerűen nem éri meg. Valószinűleg rendelkezésre állásban is jobban jössz ki, persze azt csinálsz amit szeretnél.

"Illetve a szerver bérlés/cloud használat 1-2 év múlva visszahozza a saját vas/szerver szoba árát is."

Ennek picit számolj utána. :D Combosabb szerver vas + Win2012 Std + User calok + Exchange + user calok + Office licencek, mennyire is jönne ki a 20 useredre ? Ja és userenként az 1TB tárhely?
O365-ben 5 év alatt se fizetsz ki annyit a havi bérletben és sokkilences rendelkezésre állást kapsz. Persze tudom, milyen az O365. Az MS az összes szar béta verziót alig tesztelve kitolja az élesbe, aminek az a vége, hogy szinte napi szinten lesz degraded valamelyik szolgáltatás. De azért legalább mennek, úgy ahogy.
Persze ha nem kell Exchange, hanem ráérsz hokizni valami Zimbra-szerűséggel, akkor más az ábra.
Kliensekben én először vékonyban gondolkoznék, mondjuk RPi alapokon.

szerk: coco pont megelőzött... :(

( SzBlackY | 2016. 04. 29., p – 06:31 )

Rejtett subscribe...

Fentebb már írták, hogy kezdj el pontosítani, prioritásokat belőni, mérni/tesztelni (pl. sávszél igények) stb. és több feladatot már ne vegyél fel.

Domain Controllernek, viszont nem tudom, hogy több száz kliens gép esetében lesz-e ez olyan stabil mint a Windows-os AD, ill. minden szolgáltatást amire szükségem lesz megtalálok a Linux oldalon.

Nem "illik", de nálam egy eléggé soványra tett VM egyedüli DC-ként [tipp: soha! :) ] ~80 gépnek elviszi a DC feladatait (AD, GPO). Ezt azért közel lineárisan tudod skálázni AD-vel, ha elég sok DC-d van (és jól csinálod a site kiosztást, akár úgy is, hogy minden telephelyre biztos, ami biztos, valami kenyérpiríton leteszel még egy DC-t).

Ha linux szervert választok, hogyan oldhatom meg a primary-slave szerver üzemmódot

Gondolkodhatsz aktív-aktívban (azzal kényelmesebben lehet nagyot szívni :) ), az AD-vel ugye ez megoldott, ha jól láttam azon kívül csak fájlkiszolgálás (itt aztán attól függően, hogy mennyire gond, ha kiesik válogathatsz onnan, hogy kézzel replikálsz időnként és kieséskor átütöd a DNS rekordot a pri-slave drbd és failoveren kersztül a pri-pri drbd és klaszter fájlrendszeren keresztül akár egészen a Gluster/ceph klaszter [legalább három gép!] és aktív-aktívig [májusban érdemes lesz a SambaXP előadásaiba belehallgatni/megnézni őket, a program szerint erről a felállásról többször lesz szó]) és levelezés (ott ugye az smtp miatt azonnal van failover-ed, egyszerűen az egyik MX az egyik adatközpontban, a másik a másik adatközpontban levő gépre mutat, mindkettő az amúgy is replikált AD-ból veszi a usereket/authol). Ha kell kifejezetten Exchange, akkor a Samba szvsz. felejtős (OpenChange a 4.1-nél tart, ami EoL, tavaly december óta nem sok minden változott a github repóban, nem sok jót mutat...), nézz szét valami csoportmunka + ActiveSync környékén. Vagy marad a Windows Server és az MS Exchange.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

en amondo vagyok, hogy ha nem telik csak egy kicsit is normalisabb storage-ra, akkor legyen inkabb privat felho, ott legalabb a vassal meg a HA-val (legalabbis annak low level reszevel) nem kell faradnod.

Btw. ha ez egy zoldmezos projekt, akkor melegen ajanlott email archivalast is villantani. Nagy josag...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Úgy látom, - és lehet hogy rosszul, - hogy a cloud-os szolgáltatáskimaradások, vagy egy változtatás (akár egy egyszerű beléptetés-kiléptetés) időnként és helyenként jelentős időigénye miatt, a lokális, párhuzamos megoldások ma még nem nélkülözhetők, vagy a cég jelentősen kiszolgáltatottá válik az infrastrukturális vagy a "felhős-bétás" hiányosságok miatt. Mit is lehet akkor megspórolni? (Ráadásul látok itt, az újgenerációs rendszeradminisztrátorok oldaláról egyfajta "nem akarom túlbonyolítani, - dolgozni vele, - majd a felhőszolgáltató megoldja, - nincs mit tenni", - azaz tapasztalatlanságból adódó szemléletmódot is... Persze tisztelet a kivételnek, pl. gondolom a topic-indító is ilyen..)

nyilvan a felho rendelkezesre allasa ill. elerhetosege sem 100.00%, de allitolag vannak olyan tanulmanyok, amelyek szerint egy profin osszerakott, esetleg georedundans dc sla-ja jobb, mint egy atlag kkv-e (amibe kerdezo jovoben kialakitott rendszeret is beleertem).

Ráadásul látok itt, az újgenerációs rendszeradminisztrátorok oldaláról egyfajta "nem akarom túlbonyolítani, - dolgozni vele, - majd a felhőszolgáltató megoldja, - nincs mit tenni", - azaz tapasztalatlanságból adódó szemléletmódot is.

vagy az is lehet, hogy a mindenfele szempont szerinti koltsegeket osszevetve dontenek egy felhos megoldas kozott.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

egy profin osszerakott, esetleg georedundans dc sla-ja jobb, mint egy atlag kkv-e (amibe kerdezo jovoben kialakitott rendszeret is beleertem).

Az a baj, hogy az országunk jelentős részén még mindig nem tudsz "georedundáns" szintű értelmes minőségű Internet-kapcsolatra szert tenni emberi áron. Így azért kurvanehéz felhőben gondolkodni...

internetkapcsolat amugy is minden cegnek kell, amihez szerintem egy mobil vagy mas backup nem annyira gaz.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

mar miert kene a desktopnak a neten keresztul jonnie? Masfelol a backup (jo esetben) csak ritkan lesz hasznalva...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Igen, akarok vele dolgozni. A felhős megoldást valóban csak a költséghatékonyság miatt választom. Ugye "szinte" korlátlan a keret, DE értelmetlennek látom egy 5-10-20 Millió Ft-os szerverpark felállítását egy KKV-nak. És mint a legutolsó kommentemben írtam, a bizalmas felhasználó adatok (adatbázis+webszerver+webshop) egy másik szerveren fognak futni, amiről nem én gondoskodom.

( zeller | 2016. 05. 04., sze – 09:19 )

Nekem erről a desktop virtualizáció jut eszembe: egy rakat "buta" lokális gép, site2site vpn, DC és TS funkciók az adatközpontban (két-két példányban). A gépeket valamilyen virtualizációs technológiával célszerű kialakítani, ezzel az erőforrásigényhez jobban igazodó rendszert kaptok, és a hardverproblémákat is egyszerűbb kezelni - és egy site recovery is egészen másképp, könnyebben (storage replikáció a virtualizáció alatt) megvalósítható.

Tehát az app, a böngésző, és úgy zusammen minden a szerveren kerül összerakásra, futtatásra - ezzel a lokális gépek mentése/helyreállítása/kezelése gyakorlatilag kiesik, a szoftverek telepítését, beállítását is csak a ts-e(ke)n kell elvégezni.

Az persze erősen javasolt, hogy legyen az alkalmazások hibakereséséhez, frissítések/verzióváltások előkészítéséhez illetve teszteléséhez tesztszerver _is_.

A bizalomra ("Elhihetem a datacenternek, hogy nem nézegetik a belső levelezést/adataimat") valóban szükség van - ha nincs bizalmad a szolgáltató felé, akkor fizikai szervert bérelj, titkosított diszkekkel - a bérbeadónak meg ne adj OS-oldalon semmilyen jogosultságot (ezzel viszont a te kezedbe kerül a teljes backup/recovery/high availability kérdés is, ami kellően nagy rúdaszpirin lehet). De egyszerűbb/olcsóbb a jogászokkal megnézetni, hogy mit és hogyan vállalnak - a jogszabályi kötelezettségeken felül.

A megfigyelő/vagyonvédelmi rendszer (videós móka) kialakítására én keresnék egy szakcéget, mert nem csak annyi, hogy "valahova kirakok néhány kamerát meg bedrótozom és mentem a képeket", és a dolgozókkal aláíratom a megfelelő papírokat és kirakom a matricákat, hogy kamerázott helyszín. A kamera pl. nem láthat rá a képernyőre/billentyűzetre, egymást viszont látniuk kell (ne lehessen egyik kamerához sem hozzáférni fizikailag úgy, hogy azt legalább egy másik ne rögzítse), satöbbi.

Az elhelyezésüket azért illik erősen átgondolni, nem csak a kamerák, hanem az általuk használt hálózat fizikai és logikai védelmét is tartsd szem előtt - alap, hogy a kamerák lássák egymást (ne lehessen egyik kamerához sem hozzáférni fizikailag, hogy azt legalább egy másik kamera ne lássa (egy botra kötözött festékes szivacsra is gondolj ugyanúgy, mint arra, hogy az utp-kábelt, amin a kamera kommunikál se lehessen észrevétlenül elvágni, meg persze arra is, hogy a kamerás vlan-nak legyen dedikált, fixen rendelkezésre álló sávszélessége a hálózati eszközökben)

( veyron007 | 2016. 05. 06., p – 15:16 )

Sziasztok!

Kiderítettem a pontos kliens oldali igényeket:
- Az alkalmazottak csak adminisztrációs/számlázást/logisztikai feladatokat illetve az ügyfelek kiszolgálásával kapcsolatos feladatokat fognak ellátni az irodában - webshop miatt. (Mindezt böngészőn keresztül egy weboldalon, illetve később egy Windows-os külső fejlesztésű tool-al)
- Nyomtató/scan/fax - nagy teljesítményű hálózati printerre is szükség van a számlák nyomtatása miatt. (még nem választottam típust)
- A számlázó programot a webfejlesztő cég írja
- Belső levelezés

- Szükség van tehát böngészőre (Chrome), Office (Office 365 - Office 365 Vállalati Prémium verzió), Adobe Reader, Vírusírtó (ESET NOD32), Java szoftverekre a kliens gépeken. (Windows 7 vagy Windows 8.1 - mely a fizikai hardverrel lesz megvásárolva)
- Az Office 365 license által nyújtott Exchange szolgáltatás lesz használva a belső levelezésre.

# Hardver: PC-k lesznek: Dell Optiplex 3020 + Dell U2414H + Micro Dual VESA Mount
- Illetve lesz két nagyobb UHD-s monitor ahol reklámok/vásárlási statisztikai adatok jelennek meg
- Minden gép UPS-en. (Még nem választottam, de APC-n gondolkodom)
- Azt hiszem nem szükséges egy nagy UPS-t beszerelni és kiépíteni szünetmentes aljzatokat minden box-hoz.

# A tűzjelző/Behatolás jelző rendszereket egy külső cég csinálja
# Szintén szükség lesz beléptető rendszerre és kapukra, melyet szintén egy külső cég vállal el.
# Az elektromos hálózat átvizsgálását/megerősítését ha szükséges szintén egy külső cég végzi (UPS-ek is lesznek, ill ha kell új szerződés lesz kötve az EON-nal)

# Az én feladatom a következő:
1. szerver-kliens infra tervezése/konfigurálása/karbantartása (Windows Server 2012 R2 mellett döntöttem mint szerver OS)
2. hálózat megtervezése/konfigurálása
- a kábelezésre is megvan már az alvállalkozó
3. kliensek karbantartása/telepítése/konfigurálása
4. kamera rendszer beállítása

Jelenleg itt tartok:

- Szerver szoba nem lesz, csak egy kis "zug" ahol egy rack szekrényben fog ketyegni a router, switch, UPS, illetve egy belső szerver amire a kamerák fognak rögzíteni.
- Ez a kis terem szintén zárható lesz ill. klimatizált, és megfelelt a tűzvédelmi/biztonsági előírásoknak. Valóban kicsi helyet kell elképzelni, ahova egy kb 10-15U magas rack befér, ill. egy torony szerver.
- A kamera nem felhőbe rögzít, csak helyileg. A felvételek nézegetése szintén távolról történik, ill. live a főnöki irodában.
- A felvételek 1-2 hétig lesznek tárolva, és ha kell felhőbe mentve - hétvégén.

- Windows Server 2012 R2: AD+DNS+DHCP+Remote Desktop+BitLocker+FileServer+IPSEC+sok GPO.
- Felhőben, titkosítva minden.
- A levelezés backupja a MS feladata.
- A printer management nem szükséges.

- Internet kapcsolat: Bérelt vonal 50/50 vagy 100/100. Plusz egy nem szimmetrikus 100Mbit/s-os backup vonal.

- A hálózati eszközök tekintetében pedig elbizonytalanítottatok. Itt most nem tudok dönteni.
Sokat gondolkoztam a jelenlegi helyzeten és lehetséges, hogy túlzásba viszem a CISCO-val és természetesen mással is meg lehet valósítani a "szekuritit", olcsóbban, jobban. De ezek a megoldások egyelőre nem ismertek a számomra.

pfsense

Teljesitmenyigenytol fuggoen rendes gepre vagy pl egy PC-Engines APU-ra... Nalam sok kulso irodaban viszi a PC-Engines a PFSense-el a dolgot es szukseg eseten ra lehet siman kotni az USB modemet vagy mivel alaplapon rajta vana SIM kartya es vagy 4-5 helyen csak beletoltam egy m-PCI-e HSPDA modemet a 4G backup vonalra. Ha igazan biztositani akarod tegyel be kettot irodankent. A pfsense egyebkent megoldja neked a DHCP, static DHCP, szures, snort/suricata es hasonlo gondjaidat is helyileg...

pfSense + Ubiquity - ezek az en barataim...

De ha már PFSense akkor inkább IPTables + Debian tűzfalnak a router és a SW közé, nem?
- És akkor itt megoldom a proxy-t egy squid-del.
- IPTAbles netfilter.
- A DHCP, DNS, AD, RDP, IPSEC pedig ülhet a felhőben.

- ebben az esetben lehet a file server lokálisan, és ment a felhőbe naponta a WS2012-re.

Ubiquity-t támogatom.

Hasznalj pfSenset :)

FreeBSD alapokon van - kimondottan ilyen celbol osszegyurva, es gyakorlatilag a leirasod alapjan tokeletesen neked lett kitalalva :) Telepitessel egyutt kb 1 ora utan van egy tokeletesen mukodo tuzfalad, Squid es squidguard/dansguardian, antivirus szurovel tartalomszureshez, snort/surikata csomagszuronek, 3-4 fele VPN enpoint (kliens/server) webes feluleto konfiguracio, DHCP, DNS, AVAHI(nyomtatoknak), alapbol tud VLAN - okat(Kamera rendszer kulon VLAN, WIFI Guest), alapbol van benne Captive Portal (Wifi Guest network) - gyakorlatilag ami neked kell benne van egy webes feluletu konfigban. Jah ! Es nem kell router - koszoni szepen tokeletesen routol is... Dobd be egy VirtBoxba es nezd meg. Az a fanless PC-Engines board 3 halokartyaval van - ebbol kettot hasznalhatsz uplink vonalnak es a pfSense megoldja neked az Aktiv/Passive vagy Loadbalanced modot. A harmanik kartya megy egy rendes VLAN kepes switchre es kalap-kabat.

Ameddig Debianon mindezeket osszegeszeted, ilyen szinten kb 3-4 nap es akkor meg torheted a afejed hogyan mentsd ki a konfigot kesobbre stb... Tanulni jo a Debianos modszer, de akkor sem lesz olyan mint a pfSense ami viszont mar keszen jon, elegans es biztonsagos...

Nem lattam ertelmet ... A pfSense vegul is egy customized freebsd... Lehet hozza csili-vili vasat venni de a nap vegen egy Intel CPU es nemi memoria kell neki. Amiert en a PC-engines lapot ajanlottam az a harom halokartya, a passziv hutes, 4G memoria, mSATA lemez (32 Gigas BOOOVEN SOK...) es pl nalam kulon jo hogy nincs VGA konzol csak Serial - igy kevesebb a kisertes h hozzapiszkalnak. Igazabol olyan mint egy celhardver, es 32G mSata Disk-el 4G modemmel, antennaval, kijon 200GBP korul... Annyiert nem talaltam ilyen minosegu konfigot... De nyugodtan ratolhatod rendes gepre is, csak legalabb 2 halokartya legyen benne - bar a Te esetedben a Backup vonallal ajanlanam a 3 kartyat... 2WAN+1LAN(VLAN)... Jah es KB 7-14W a fogyasztasa :)

Rack-be szerelhető "mini" vasat szánok neki pl. egy HP Proliant DL320 gen8 v2. --> Intel Pentium CPU 3,1GHz (2core,2 thread), 2GB RAM, 3 nic-el. 2x500GB HDD (RAID0). --> 300.000 kb.

Amit rátennék:
- squid proxy + squidquard
- fw funckiók
- vlan-ok kezelése
- carp
- dhcp
- dns

Lehet túlzás a vas, viszont ezzel elmegy 10 évig és nem kell hozzányúlni, hacsak a HDD meg nem hal :)

Fölötte egy router dual WAN porttal (Őt még nem választottam ki).
Alatta két db 24 v 48 portos Gigabites/PoE-es Ubiquity switch a kamera/PC/IP tel/printer-nek.

toljal neki tobb RAM-ot :) Ilyen vasat raksz ala es nem adsz neki enni :)
Es minek neki 500G Winyo ? A budos eletbe nem tolti be...

Filesystem Size Used Avail Capacity Mounted on
/dev/ufsid/563bfd38949b7521 11G 1.2G 8.5G 12% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 290M 916K 266M 0% /tmp
/dev/md1 726M 175M 493M 26% /var
devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev
procfs 4.0K 4.0K 0B 100% /proc

Ez egy fullosan bekonfigolt pfSense - Hova ide 500G - ugysem tudod kihasznalni... Max a logfileokat irkalja meg neha-neha megboki a konfiguraciot...

Kliens oldali igenyek es a szerver oldali megoldas kicsit olyan agyuval verebre.
Lenyegeben lesz egy bolt ahol a vevo a webshopban rendelt dolgot atveszi es az otani szemelyzet az eldassal kapcsolatos muveletet vegzi webes alkalamzasokkal. Ha tenyleg ennyi a feladat ide szerintem tok folosleges a vpn, AD es az ezzel kapcsolatos moka. Jobban jarsz egy vekony kliensses megoldassal. Gep rajta a bongeszo, nyomtato IP-n direkt felveszed, esetleg a tuzfalon csak a webes alkalmazasok fele engeded a forgalmat. Ha gaz van kiviszel egy masik gepet felveszed a nyomtatot es kedvencekbe berakod azt a par fontos URL-t es nem kell ide 100/100-as net.

Nyomtató: lehet jobban jársz ha bérelsz. Vannak cégek amik ilyesmivel foglalkoznak, megadod nekik a várható felhasználást (pl. havi 500 színes és 5000 ff nyomat), aztán hoznak olyan (célszerűen multifunkciós) nyomtatót ami erre megfelel. Ha probléma van ők javítják, neked (vagy annak aki helyben lesz) csak annyi a dolgod hogy a tonert cserélj ha szükséges. Illetve havonta küldöd a számlálóállást és fizetik a számlát.
Ha a nyomtató SPoF akkor célszerű két kisebb nyomtatót berakni.

Az 50/50 és 100/100 szerintem is overkill, ezt a böngészős kattintgatóst egy 10/10-es net simán kiszolgálja. Persze ha nincs nagy árkülönbség akkor én se vennék kisebbet.

Sok mindent nem látni még ebben, mi miként fog történni, ami technikai szinten nem világos, hogy w2k12r2 esetén a "Remote Desktop" mit jelent? Mert ha terminál kiszolgáló funkció és egyetlen szerverre gondoltál, akkor az AD-vel nem fogják szeretni egymást. Ez a Windows felhőben fog futni vagy ez lesz a torony szerver? Ha felhő, akkor a DHCP-t például távolról nyújtod vastag kliensek (Windows PC) számára? Ha PC, akkor mi a "remote desktop"?

- Terminal szerver nem lesz.
- Azure vagy AWS felhőben fog futni az AD.
- Az AD mellé szeretném a DHCP-t ill DNS-t. Azonban ha a PFSense megy be tűzfalnak (esetleg routernek is egyben) akkor elgondolkodom rajta, hogy ide telepítsem ezt a két service-t.

- A hátránya PFSense-nek első körben csak annyi, hogy a redundanciát még nem tudom hogy oldanám meg vele. Ha kiesik elmegy a tűzfal, a route és dhcp/DNS is.