Stejne jako oskenovat, co ti tam bezi a dostat se ti tam bez zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou PHPkovinu a data, ktery by bylo potreba chranit, jsou primo v DB, kam ty PHP spagety vidi.
A co ted s tim, vypneme to vsehno? ;)
Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad tim clovek zamysli, zasifrovat vsechno taky neni reseni.
Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu nosit klicenku s trhavinou na flashkach, mame vymluvu, proc plosne nasadit sifrovani, proc se nam nepujde dostat do racku neautorizovane, aniz by to neodmazlo klice a neshodilo vsehno chraneny (tj. abys nam fakt nechtel otevrit ten rack).
Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak muzem nase systemy postupne posouvat vic smerem plausible deniability, tj. soukromi je level jedna, level nuda, ale co nam to umozni je ochranit i adminy pred tim, aby vedeli, co clen bezi.
Neumel jsem si bez GDPR predstavit, jak zvysovat zabezpeceni bez toho, aby to vypadalo, jako kdyz se chystame hostovat tunu detskyho porna a lokalni pobocku CIA. Jenom to nebude vsehno hned - a nektery levely zabezpeceni na sharovanym hardwaru ani nepujde udelat.
Chci:
- sifrovani v ZoL
- aby clen mel moznost klic per dataset neulozit, ale zadat si ho sam pres bezpecny kanal (ssh/https api call)
- monitoring otevreni racku co bez nahlaseni predem donuti masiny smazat klice z RAM
Ale tohle je furt malo, pokud admini nemaji vedet, co clen bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam nepomuze, takze resim, jak zahostovat single board desky pro cleny, kteri chteji mit moznost nejcitlivejsi data mit fakt soukrome.
Ve finale:
- budes mit moznost data na VPS sifrovat svymi hesly, ktera se u nas nebudou ukladat (prusvih je, ze my nemame jak dokazat, ze jsme to nikde neulozili)
- pri neautorizovanym pristupu do racku se klice smaznou, to samy pri rebootu/resetu a je pak na tobe zvazit, jestli je OK data uz odemknout
- budes mit moznost nejcitlivejsi data vysoupnout vedle po siti na svuj dedikovanej systemek kalibru ARM Cortex A53, do budoucna RISC-V
Problem nastava, kdyz s adminkem pujde do datacentra nekdo sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, pak admin nema moznost ani nejak kliknout smazani klicu, nebo aspon nejakej counter na webu ve smyslu kanarka, ktery bude pocitat pocet podobnych incidentu.
Shared computing ma svoje limity, bohuzel, jestli sledujes, kam tim mirim.
GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale do budoucna nam dava zaminku jit na to vic z husta, co se soukromi tyce.
Muze nam pak nekdo nadavat, ze delame hosting detskyho porna a teroristum, kdyz mame racky obehnany pomalu ziletkovym dratem? Nemuze, at si stezuje v Bruselu.
Za mne dobry, ale nebude to hned. A v prvni vlne bude hlavne to papirovani. V druhy vlne se musime zbavit nedostacujiciho OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi bezpecnostni politiku - a je odspoda nahoru cely podepsany a verifikovatelny.
/snajpa
> On 30 Jan 2018, at 23:41, Jaroslav Skrivan <skrivy(a)skrivy.net> wrote:
>
> Jenom moje osobni zkusenost - odnest si cizi disky z datacentra neni zas takovy problem, jak se na prvni pohled muze zdat.
> From: Pavel Snajdr
> Sent: 1/30/2018 10:49 PM
> To: vpsFree.cz Community list
> Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
>
> Ahoj,
>
> GDPR je, pokud to dobre chapu, totalni nesmysl, z kteryho jsou vsichni vyjukani uplne, ale naprosto totalne zbytecne.
>
> Podivej se, co bezime za procesory.
>
> Jak ma nekdo neco v takovym stavu vubec industry-wide za neco rucit?
>
> Za mne je GDPR o tom a pouze o tom, ze musime podepsat papir s lidmi, co maji admin pristupy, aby acknuli oficialne svoji zodpovednost.
>
> V seznamu clenu uz ted mame jenom nejnutnejsi udaje (podle posledni zkusenosti s PCR a PSR jim k identifikaci ani to nemusi stacit...).
>
> Ve stanovach mame zakotvenou ochranu dat clenu uz od zacatku.
>
> Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma zodpovednost, best practices v ohledu bezpecnosti davno sleduje.
>
> A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to vyresi, tak se rovnou zeptam - a borci, jak se k tomu asi programy na ty masine dostanou? Hint: stejne musi byt data odemcena pri behu. A ze se k nim neco dostane za behu je mnoooohem pravdepodobnejsi, nez ze nam z hlidanyho datacentra nekdo ukradne disky a vycte si neco offline.
>
> Tedy, muj nazor je, ze vubec neni potreba panikarit a natoz se uchylovat k reseni stylem ‘radsi to na vpsFree nedam vubec’. To ty servery muzeme rovnou vypnout totiz - a cely to zabalit s tim, ze jsme se nechali prevalcovat byrokratama.
>
> /snajpa
> (Pavel Snajdr)
> (Predseda vpsFree.cz)
> (+420 720 107 791)
>
> > On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN <lukas(a)aiken.cz> wrote:
> >
> > Ahoj,
> >
> > pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě
> > (byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to
> > asi příliš řešit nelze, protože by to pro spolek znamenalo velkou
> > administrativní zátěž a značný nárůst nákladů.
> >
> > Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery
> > vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se
> > všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad
> > různých ustanovení směrnice).
> >
> > Lukáš Jelínek
> >
> >
> >
> >> Ahoj ve spolek!
> >>
> >> Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě
> >> blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu
> >> zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree.
> >>
> >> Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní
> >> údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten
> >> webserver, kde se logují IP adresy, které jsou rovněž považovány za
> >> osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce
> >> osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů
> >> rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv
> >> poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v
> >> postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah
> >> zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi
> >> nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě
> >> správci osobních údajů a vpsFree je zpracovatelem osobních údajů.
> >>
> >> Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree?
> >> V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno
> >> něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky
> >> garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách
> >> jsou kompetentnější členové v této věci jako já a tak bých rád otevřel
> >> diskusi.
> >>
> >> Honza.
> >>
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list(a)lists.vpsfree.cz
> > http://lists.vpsfree.cz/listinfo/community-list
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
Ahoj ve spolek!
Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě
blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu
zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree.
Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní
údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten webserver,
kde se logují IP adresy, které jsou rovněž považovány za osobní údaje.
Díky tomu jsme z pohledu GDPR považování za správce osobních údajů.
Podle článku 4 GDPR se zpracovaním osobních údajů rozumí také ukládání
osobních údajů. Z toho plyne, že jakýkoliv poskytovatel cloudových
služeb, hostingu, VPS, atd. je vůči správci v postavení zpracovatele
osobních údajů. Článek 28 GDPR potom řeší vztah zpracovatele a správce,
kde mj. požaduje nějaký smluvní vztah mezi nimi. Když to převedu na
protředí vpsFree tak členové jsou v podstatě správci osobních údajů a
vpsFree je zpracovatelem osobních údajů.
Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? V
podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno něčím
nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky garantuje, že
data nebudou uložena mimo EU. Věřím, že v našich řadách jsou
kompetentnější členové v této věci jako já a tak bých rád otevřel
diskusi.
Honza.
--
Ing. Jan Dvorak
****************************************
Ing. Jan Dvorak
Fischerova 690/23
779 00 Olomouc, Nove Sady
Czech Republic
****************************************
Tel: +420 603 444 240
E-mail: jan.dvorak(a)dvorak-sw.com
Web: http://www.dvorak-sw.com
****************************************
Ahoj,
podle mojí interpretace vpsFree poskytuje pouze technické prostředky nad kterými členové teprve zpracovavaji (ukládají) osobní udaje.
Tj. kdyby došlo na lámání chleba, tak člen (správce dat) nemůže prokázat v jakém rozsahu vlastně písemné někoho pověřil (vpsFree), aby mu pomáhal data zpracovávat bez ohledu na to, komu patří železo a kdo spravuje OS. Bezpečnost zajišťuje spravce dat.
Situace by se zkomplikovala jen v případě, pokud by technické prostředky nebyly bezpečné a uživateli by se mazal med kolem huby, ale to je extrem.
S pozdravemPetr Juhaňák
petr(a)juhanak.cz | +420 739 639 132
-------- Původní zpráva --------
Od: Lukáš Jelínek - AIKEN <lukas(a)aiken.cz>
Datum: 30.01.18 22:10 (GMT+01:00)
Komu: "community-list(a)lists.vpsfree.cz >> community-list" <community-list(a)lists.vpsfree.cz>
Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
Ahoj,
pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě
(byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to
asi příliš řešit nelze, protože by to pro spolek znamenalo velkou
administrativní zátěž a značný nárůst nákladů.
Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery
vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se
všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad
různých ustanovení směrnice).
Lukáš Jelínek
> Ahoj ve spolek!
>
> Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě
> blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu
> zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree.
>
> Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní
> údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten
> webserver, kde se logují IP adresy, které jsou rovněž považovány za
> osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce
> osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů
> rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv
> poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v
> postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah
> zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi
> nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě
> správci osobních údajů a vpsFree je zpracovatelem osobních údajů.
>
> Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree?
> V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno
> něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky
> garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách
> jsou kompetentnější členové v této věci jako já a tak bých rád otevřel
> diskusi.
>
> Honza.
>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
nesetkal se nekdo z vas s padajicim guestem v KVM? Jedine, co vzdy najdu
v logu je:
qemu-system-x86_64: Virtqueue size exceeded
nebo
qemu-system-x86_64: virtio: bogus descriptor or out of resources
Bohuzel jsem stale neprisel, cim by to mohlo byt. Host system jsem
upgradoval z Alpine 3.5 na Alpine 3.7 s tim, ze to byl nejaky bug, ale
nevypada to. Guest system je Debian 8. CPU v guestu vytizene vubec neni
a memory taky vypada OK az do "zaseknuti" stroje.
// J
Zdravim,
rad bych se zeptal, jak vytvorim na Debianu init script pro appku (vetsinou
node.js) a nastavim ho aby se spoustel pri startu systemu. Aktualne
pouzivam detasovany screen a v nem shell pro kazdou appku, ale nechce se mi
vse manualne spoustet po kazdem "Neplanovanem vypdadku".
Uz jsem stravil nekolik hodin snahou dohledat, jak to v Debianu chodi.
Zkusil jsem treba tenhle script: https://gist.github.com/peterhost/715255
(a nekolik dalsich) upravit a dat do /etc/init.d/my-simple. Dostavam chyby:
$ service my-simple start
Failed to start my-simple.service: Unit my-simple.service failed to load:
No such file or directory.
$ update-rc.d "my-simple" enable
update-rc.d: error: no runlevel symlinks to modify, aborting!
Myslel jsem, ze .service soubory patri pod systemd a ze Debian pouziva init
scripty a ze service je tool na spravu init scriptu podobne jako v Gentoo
je treba rc-update. Chyby jsem zkousel googlit, ale nasel jsem jen problemy
se spatne nainstalovanymi aplikacemi.
Jestli me muzete nakopnout, nebo poradit, budu rad.
Zdar,
Jakub
Nazdar,
mam server s nginix + php7-fpm + ispconfig
vsymol som si jednu nebezpecnu vec, ked zavola v php funkciu
shell_exec a vykonam prikaz napriklad cat, tak viem citat subory aj
inych webov
napriklad viem precitat subor
-rw-r--r-- 1 web2 client1 /var/www/clients/client1/web2/web/index.php
z pricinku
drwxr-x--x 8 web2 client1 /var/www/clients/client1/web2/web
pricom php skritp je spusteny ako web1:client0
chcel by som zvysit bezpecnost na servery, a zamedzit moznost citat
takto data z inych webov
potreboval by som poradit nejaky dobry sposob,
- som otvoreny aj inemu control panelu ako ispconfig, ale musi
obsohovat podobnu funkcionalitu
- nechcem zakazat shell_exec v php potrebujem ho
- rozmyslal som na chroot alebo kontajnermy ale potrebujem trocha poradit
Zdravim,
mam na VPS nakonfigurovany postfix, dovecot a spamassasin. Spam je spravne
detekovany ale chcel by som, aby sa hadzal do osobitneho adresara (SPAM
alebo Junk...). Nemam velke skusenosti s mailovymi servermi. Toto je moj
osobny mail kde sa snazim naucit co ako funguje. Skusal som hladat navody
na internete a nieco som aj skusal ale maily mi potom nechodili vobec alebo
chodili s velmi velkym oneskorenim a neviem preco.
Mohol by ma niekto nasmerovat? Chcel by som v prvom rade pochopit ako veci
funguju, lenze co som videl boli vsetko iba navody krok za krokom bez
vysvetlenia principu. Potom sa tazko hlada chyba ked neviem ani co robim.
Vdaka za akukolvek pomoc.
Oto
Hezký leden všem,
pojďte s námi přednášet na InstallFest! Hledáme (spolu)přednášející,
kteří by udělali nějaká témata pro začátečníky: best practices, jak
začít s Linuxem, nějaké služby, klidně i hardware, vývoj, co vás
napadne. Nebojte se do toho a pojďte s námi udělat super konferenci.
https://installfest.cz/if18/
--
Petr Krčmář
vpsFree.cz
EN-TLDR: I have a patch for Meltdown ready. Do we deploy now or wait
until after midnight?
Mam naportovany patch z RHEL6 na nase OpenVZ jadro.
Taky overenou funkcnost na trech serverech (jeden z toho je node1.pgnd,
dva testovaci).
Jdeme to aplikovat hned? Prezijete vypadek?
/snajpa
Ahoj, o víkendu 3. a 4. března proběhne desátý ročník obnovené
konference InstallFest [1]. Máme se Snajpou přihlášené přednášky, opět
tam budeme mít stánek s kávou a rádi vás tam potkáme.
Píšu ale hlavně proto, že ještě běží přihlašování přednášek a bylo by
fajn, kdyby se nám tam sešlo víc zajímavých témat – pomůže to vpsFree,
ale hlavně konferenci jako takové, aby bylo co poslouchat. Pokud máte
nějaký nápad, určitě ho přihlaste. Nebojte se toho, kdybyste potřebovali
pomoct s obsahem přednášky, abstraktem nebo třeba přípravou osnovy, jsem
vám k dispozici.
[1]: https://installfest.cz/if18/
--
Petr Krčmář
vpsFree.cz
