Two-Factor Auth Destekli OpenVPN Server Kurulumu

IT altyapılarının güvenilirliğini ve bağlı olarak sürekliliğini sağlamak üzere uygulanması gereken süreç disiplinlerinde kritik data içeren mecralara erişimlerde sıkı güvenlik prosedürleri izlenmesi gerekiyor. Bu anlamda özellikle PCI-DSS ya da ISO 27001 standartlarına tabii olan ya da olmak isteyen firmaların, kendi networklerine “dışarıdan” erişim ihtiyacının bulunması durumunda implemente edecekleri VPN çözümlerinin, bahsi geçen güvenlik standartlarına uygun olması gerekiyor. Örnek olarak PCI-DSS uyumluluğu için kullanılan VPN çözümünde kimlik doğrulama işlemi en az iki aşamalı olarak gerçekleştirilmek durumunda. Bu zorunluluk PCS-DSS V3’de şu şekilde tarif edilmiş durumda:

Implement Strong Access Control Measures 8.3 – Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance). Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. 8.2 Authentication methods – Something you know, such as a password or passphrase – Something you have, such as a token device or smart card – Something you are, such as a biometric.

Bu tanıma göre, networkünüze uzaktan erişim sağlayacak her türlü bağlantı için yapılacak kimlik denetimlerinde madde 8.2’de belirtilen metodlardan en az ikisinin kullanılması gerekiyor. Günümüzde yaygın olarak kullanılan SSL VPN çözümlerinde PKI altyapısı kullanılarak, bir username üzerinden key ibraz etmek sureti ile kimlik denetimi gerçekleştirilip bağlantı kuruluyor. Ancak bu tek yönlü kimlik denetimi, anlaşıldığı üzere yeterli değil. Bu nedenle kullandığınız VPN çözümünün username/ password (ya da key) ibraz etmeye ek olarak token ya da bir biometric denetim mekanizmasını destekliyor olması gerekiyor. Biometric denetim mekanizmalarının oldukça sınırlayıcı ve maliyetli çözümler olduğunu düşünürsek, iki yönlü doğrulama için username + token mekanizmalarını birlikte kullanmak konunun pratik çözümü olacaktır. İşte bu konudan hareketle bu yazıda, bir SSL VPN implementastonu olan OpenVPN ve Google Authenticator kullanılarak two-factor authentication destekleyen bir VPN sunucusu kurulumundan bahsedeceğim. En nihayetinde halihazırda kullandığınız OpenVPN altyapınıza yazıda anlatıldığı şekli ile google authenticator entegrasyonu da yapabilirsiniz.


Devamini okuyun: Two-Factor Auth Destekli OpenVPN Server Kurulumu


Cagri Ersen tarafından Syslogs adresinde yayınlandı. | Permalink | Etiketler: ,

30 Kasım 2014

Posted In: *nix, Genel, installation, openvpn, security

Etiketler:,

İnternet: Son Söz Söylenmedi

Günlerdir iPhone’un yeni modeli konuşuluyor. Gazeteler ve haber portalları reklam kokan haberlerden geçilmiyor. İnsanlar iPhone’un yeni modelini bir an önce satın alabilmek için türlü çılgınlıklar yapıyor. Cumhurbaşkanı Recep Tayyip Erdoğan da bu durumu eleştiriyor [1]:

İnsanlar o marka telefonu alabilmek için gece dahi saatlerce kuyrukta bekliyorlar. Bu marka her yıl model çıkardığı halde, modeller arasında çok büyük farklılıklar da yok ha, bunu da söyleyeyim. Tanınmışlık sayesinde bu uzun kuyrukları oluşturabiliyorlar. Burada bir çok arkadaşımız da bunu biliyor. Aslında satılan telefon değil, satılan o telefonun markası. ‘Bak yenisini aldım, bu.’

iPhone’un modelleri arasında fark olup olmadığını bilmiyorum. Fakat Erdoğan, satılanın telefon değil marka olduğunu söylerken haksız sayılmaz. Ne yazık ki Erdoğan’ın bu sözleri, bazılarınca alaya alındı. Hatta Erdoğan’ın iPhone eleştirisinden sonra iPhone’a yakınlık duymaya başlamış, ilk fırsatta iPhone almayı düşünen muhalifler de olabilir.

Viyana merkezli Uluslararası Basın Enstitüsü (IPI) ile New York merkezli Gazetecileri Koruma Komitesi’nin (CPJ) ortaklaşa oluşturduğu basın özgürlüğü heyeti ile yapılan toplantıda ise Erdoğan “Medyaya hakaret özgürlüğü asla verilmemeli. İnternete olan karşıtlığım her geçen gün daha da artıyor” dedi [2]. Erdoğan’ın bu sözlerinden sonra sosyal medya, doğal olarak, çalkalandı. Bunda çok da kızacak bir şey yoktu. Erdoğan, iktidar sahibi olarak kaygılarını son derece açık bir dille ifade etmişti. Geçtiğimiz günlerde Facebook, Twitter, Google ve Microsoft’un da katılımıyla gerçekleşen AB (Avrupa Birliği) toplantısının gündemi de internetteki fanatiklere karşı mücadeleydi. Son zamanlarda, sosyal medyanın kökten dinci örgütler için taraftar bulma mekanı haline gelmesi AB’yi kökten örgütlenmelere karşı harekete geçirmişti [3]. ABD’nin sosyal ağlardan bilgi talep ettiği ve kullanıcıların bu konuda haberdar edilmediği artık gizlenmiyor bile [4]. Dolayısıyla, internetten rahatsızlık sadece Erdoğan’a özgü bir durum değil. Tüm iktidarlar interneti bir şekilde (sansürle ve/veya gözetimle) kontrol etmeye çabalıyor. Bunu da teknolojik ve politik kapasiteleri doğrultusunda gerçekleştirebiliyorlar.

Ancak ben Erdoğan’ın yerinde olsaydım, internetten rahatsızlığımı düşünerek, iPhone’u pek eleştirmezdim. Çünkü iPhone ve benzerleri tam da Erdoğan’ın (ve diğer iktidar sahiplerinin) hayalindeki interneti oluşturacak potansiyele sahipler. Bu onların meselesi…

Bizim meselemize gelince…

Eğer interneti soldan tartışacaksak iki bakış açısından, teknolojik belirlenimcilikten ve teknolojinin tarafsızlığından, özenle uzak durmamız gerekiyor. Çünkü her iki bakış açısı da teknolojiyi durağan bir şey (thing) olarak değerlendirmekte.

Teknolojik belirlenimcilik, teknolojinin tek yönlü olarak (olumlu ya da olumsuz şekilde) toplumu dönüştürdüğünü savunur. Telefon bire bir (one to one), radyo ve televizyon birden çoğa (one to many), internet de çoktan çoğa (many to many) iletişime olanak verir. Açıkça ya da üstü kapalı olarak bilgisayar ağlarının teknik alt yapısının toplumsal ilişkileri belirleyeceği varsayılır. Fakat yeni toplumsal hareketlerin örgütlenip başkaldırmasını, şirketlerin yeni iş modelleriyle sömürüyü yoğunlaştırmasını ve hükümetlerin vatandaşlarını gözetlemesini sağlayan aynı teknik altyapıdır. Bu durumu dikkate almadan, bütünün belirli bir parçasına odaklanıp iyimser ya da kötümser yorumlar yapılabilir. İşgal Et! (Occupy!) hareketlerine bakarak sosyal medya yüceltilebilir; artan gözetim uygulamaları (dinlenen telefonlar, sokakları gözetleyen kapalı devre kameralar, büyük veri, derin paket inceleme vb) nedeniyle kara senaryolar yazılabilir.

Bazılarına göre ise teknoloji ne iyidir ne kötüdür; tarafsızdır. Herhangi bir teknoloji farklı amaçlar için kullanılabilir. Kısmen doğrudur; en azından kullanıcının iradesini dikkate almasıyla teknolojik belirlenimcilikten daha ileri bir noktadadır. Kullanıcıların kültürü ve teknolojiyi nasıl sahiplendikleri önemlidir. Çocukluğundan beri bilişim teknolojileri ile haşır neşir olan bir kuşak ile kırkından sonra internetle tanışan bir kuşağın bilişim teknolojilerini kullanımı farklı olacaktır. Ayrıca kullanıcıların birbirini tanıdığı veya benzer kültürlerden geldiği homojen bir topluluğun bilgisayar ağını sahiplenmesi heterojen toplulukların bilgisayar ağını sahiplenmesinden farklıdır. Yine kullanıcıdan yola çıkarak, gözetimi ve internetin ticarileşmesini hükümetlerin ve şirketlerin kötü kullanımıyla, ağdaki demokratik örgütlenmeleri yeni toplumsal hareketlerin iyi kullanımıyla açıklamak da mümkündür. Teknolojinin tarafsızlığından yola çıkarak, “zaten bugün kötü işlerde kullanılan büyük veri de devrimden sonra toplum yararına kullanılacaktır” da denilebilir.

Ama insan iradesi, yalnızca teknolojinin kullanımında değil tasarımında da yer alır. Teknoloji bir şey (thing) değil, farklı tarafların iradesiyle şekillenen süreçtir. Varsayılanın aksine herhangi bir teknolojinin toplumsal kabulünü sağlayan yalnızca verimlilik değildir. Feenberg (2012) bisiklet örneğini verir. Bugün bisikletlerdeki tekerleklerin eşit boyutlarda olmasını olağan karşılıyoruz. Oysa ilk başta ön tekerleği daha büyük olan bisikletler de bir seçenekti. Ön tekerleği büyük olan bisikletler hızlarıyla, iki tekerliği eşit olanlar ise daha dengeli olmaları ile öne çıkıyorlardı. İnsanlar tercihlerini hızdan yana değil dengeden yana kullandılar ve büyük tekerlekli bisikletler tarihin bir döneminde donup kalırken sonraki bisikletler kazanan modeli takip etti.

Yapılandırmacı (constructivist) yaklaşım bu durumu teknolojilerin yorumsal esnekliği ile açıklar. Yapılandırmacılara göre herhangi bir teknolojinin ne için kullanılacağı açık seçik belli olana dek tasarımı standartlaştırılamaz. İlk aşamalarda farklı tasarımlar yarışır; ama bu yarışın sonucunu belirleyen her zaman verimlilik olmaz. Yukarıdaki bisiklet örneğinde belirtildiği tasarımın ardında birbiriyle çekişen kaygılar olabilir. Bu tasarımlardan biri galip geldiğinde, teknolojinin tasarımı da o çizgide gelişir ve geliştirilen teknoloji farklı koşullar oluşana kadar kararlılığını sürdürür. Örneğin bugün küçük yaşlardan itibaren bir parçamız haline gelen telefonun ilk çıkış amacı devlet işlerinde kullanımdı. Kadınlar telefonu ailelerinin sosyal yaşamlarını düzenlemek için kullanmaya başladığında bu durum mühendislerin pek hoşuna gitmemişti. İlginç olarak telefon 1920 yılına kadar, şirketlerin abonelerine canlı yayın ulaştırdığı bir yayın (broadcast) teknolojisi olarak kullanıldı (age). Fakat bildiğimiz gibi telefon kişiler arası iletişimin aracı olarak kararlı hale geldi ve tasarımlar bu yönde gelişti. Ta ki bilişim teknolojileriyle akıllı hale gelip yeni bir kararsızlığa sürüklenene dek.

Radyo ve televizyonun ilk mucitlerinin kafasında da bugünkünden farklı amaçlar vardı. Radyonun ilk günlerinde eğitim ve kamu programcılığı hakimdi. Televizyon ise daha çok bir eğitim ya da gözetim aracı olarak düşünülüyordu. Ancak daha sonra her ikisi de hızla eğlence sektörünün hakimiyetine girdi ve sonraki gelişimleri de bu doğrultuda oldu. Diğer kullanım alanları da varlığını ikincil olarak sürdürdü. Ama asıl belirleyici olan eğlence sektörünün gereksinimleriydi (age).

Dolayısıyla, teknolojik belirlenimciliğin ya da teknolojinin tarafsızlığı görüşünün etkisinde olanlar teknolojinin olumsallığını, çıkışından kararlı hale gelene kadarki mücadeleyi gözardı ederek interneti olmuş bitmiş bir şey olarak tartışmaktadır. Bunun sonucunda, tarihin belirli bir dönemine ait olgular genelleştirilerek internetin toplum üzerindeki olumlu ya da olumsuz etkilerinden bahsedilebilmektedir. Bunun doğal sonucu olarak bazıları internette artan metalaşmayı ve gözetimi hissettikçe kötümserleşirken, bazıları da Gezi’deki sosyal medya kullanımından yola çıkarak interneti fetişleştirmektedir. Son yıllarda, şirketlerin artan hakimiyeti ile internetin de radyo ve televizyonla aynı kaderi paylaştığını düşünenler de vardır. Şirketlerin interneti kendi çıkarları doğrultusunda yeniden (!) tasarlamaya çabaladığı doğrudur. Fakat internetin kararlı hale gelip tasarımında sona gelindiğini söylemek için henüz erkendir (Feenberg ve Bakardjieva, 2004).

Teknolojinin gelişim sürecinde bilim insanlarının, mühendislerin, tasarımcıların, yöneticilerin, sermaye sahiplerinin ve kullanıcıların çıkar ve görüşleri çarpışır. Şirketler internetin mimarisine en baştan, ilk geliştirilme aşamasında müdahil olsalardı, kuşkusuz bugün başka bir internetimiz olacaktı. Bugünkü internet yerine kapitalizmin azami kar, rekabet, dışlayıcılık vb normlarını içeren bir internetimiz de olabilirdi. Neyse ki internetin ilk tasarımının arkasındaki aktörlerin temel kaygısı kalımlılıktı (survivability). Amerikan ordusu, merkeze yapılacak herhangi bir saldırının tüm iletişim ağını kesmesini istemiyordu. Bu yüzden, hiyerarşik olmayan ve ağın düğümleri arasında gereksiz (redundant) bağlantılar da içeren bir yapı hedeflendi. Bu tasarımsal tercih internetin sonraki gelişimine de yön verecek, onu sağlam ve değişen ihtiyaçlara yanıt verebilen esnek bir teknoloji yapacaktı. Şirketlerin internete ilgisi ise çok daha sonra oldu. Öyle olmasaydı, tasarımda, kalımlılık yerine kontrol daha ön planda olacak ve ağın düğümleri arasındaki gereksiz bağlantılardan tasarruf edebilmek için A ve B gibi iki düğüm arasında tek bir yol yeterli olacaktı.

Mühendislik perspektifinden ele alındığında ağın kullanım protokollerinin zarif ve verimli tasarımlara olanak verebilmesi için protokollerin oldukça basit tutulması gerekiyordu. Ayrıca ağın gelişimi ve büyümesi için mimarisi açık uçlu kurulmalıydı. Ağın merkezi yönetimi toplumsal bir karardı ve ne mutlu ki mühendislerin ağı ve kullanıcıları kontrol etmek gibi bir kaygısı yoktu (Feenberg, 2012).

İnternetin öncüleri kendilerini bugünkünden farklı, hiçbir kuralın olmadığı bir alanda bulmuşlardı. İnterneti beraberce inşa ettiler. Gönüllülük, işbirliği ve paylaşım bu inşa sürecinin temelini oluşturdu. Ağın açık uçlu mimarisi e-posta ve www (world wide web) gibi inovasyonların da önünü açtı. İnternetin önceli ARPANET’in henüz birkaç üniversiteyi bağladığı bir dönemde ortaya çıkan e-posta programı ilk başta (kadınların telefon kullanımı örneğinde olduğu gibi) gereksiz bir sosyallik olarak görüldü; ama kısa bir süre sonra e-postanın topluluk inşasındaki rolü fark edildi ve e-posta deneylerine izin verildi. Daha sonra Tim Berners-Lee, www’yi icat etti. Kapitalizmin internete henüz bulaşmadığı günlerde icat edilen her iki teknoloji de enformasyonun paylaşımını kolaylaştırdı ve internet topluluklarının oluşumunun önünü açtı. Her iki teknoloji, internet teknolojisinin açık mimarisinin üzerinde yükselerek kendi yapılarında da bu açıklığı devam ettirdiler. İnternetin bu evresinde teknolojiyi belirleyen hükümetler ve şirketler değil, ağdaki bilim insanlarının ve mühendislerin buluşları oldu.

Sonraki evrede, üniversitelerin ve araştırma laboratuvarlarının dışından sıradan insanların da internete müdahalesini gördük. Kullanıcılar, askeri araştırmacıların bilgi paylaşımı için geliştirilmiş bir teknolojiye yeni işlevler kazandırarak onun iletişim potansiyelini artırdılar. Kullanıcılar teknolojiyi tasarımcılarından farklı bir açıdan ele alıp internet teknolojisinin açık uçluluğundan faydalanarak onu yeniden yorumladılar. Ancak teknolojinin yeniden yorumlanması, teknoloji açık uçluluğunu koruduğu sürece gerçekleşebilirdi. Şirketlerin internete en olumsuz etkisi de metalaşmayı interneti ve internet teknolojilerini sınırlayarak gerçekleştirmeye girişmeleri oldu.

Şu an şirketlerin yoğun baskılarına rağmen şirketlerin bir zaferinden söz edemeyiz. Mücadele devam ediyor, şirketlerin interneti ticarileştirmeye yönelik hamlelerine internetin (ve tarihin) öznesi insanın yaratıcı hamlelerine şahit oluyoruz. İnternetin geleceğini üç farklı modelin mücadelesi belirleyecek (Feenberg, 2012).

Birinci model, enformasyon modelidir ve internette enformasyonun dağıtımını hedefler. İnternetin ilk günlerinden beri varlığını sürdüren bir modeldir. Kuşkusuz daha sonra da varlığını devam ettirecektir. Ama kişiler arası iletişim, enformasyon değişiminden daha çekici gelmektedir.

İkinci model, tüketim modeli olarak adlandırılır. İnterneti küresel bir alışveriş merkezine çevirmeyi hedefler. Kullanıcılar arası iletişime asgari düzeyde gereksinim duyulur. Ayrıca eğlence endüstrisi ve servis sağlayıcılar, interneti de televizyonlaştırmak için hem yasal hem de teknik alanda yoğun bir faaliyet göstermektedir.

Üçüncü model ise topluluk modelidir. İnternetin en başından beri amacı iletişimdir. E-postalar, tartışma listeleri, forumlar, bilgisayar konferansları kişiler arası iletişimin ilk örnekleridir. Ancak bu uygulamalar internetin ilk günlerinde, internetin ilk kullanıcıları (aynı zaman geliştiricileri) arasında bir topluluk bilinci oluşturabilmesine karşın internet heterojenleştikçe (bilim insanları ve bilgisayar meraklılarının dışında insanlar internete katıldıkça) yetersiz kaldı. Ama 2000li yıllarda çıkan, önceki iletişim uygulamalarındaki eğilimleri ileriye taşıyan sosyal medya ve web 2.0 uygulamaları, hem toplumun daha geniş kesimlerini topluluklara kattı hem de topluluk üyeleri arasındaki etkileşimi artırdı. Bu yeni toplulukların temelinde karşılıklılık yatıyordu; insanlar önceki topluluk deneyimlerinde tartışma listelerini ya da forumları sadece izlemekle yetinebiliyorlar ve kendilerini gizleyebiliyorlardı. Sosyal medya ise insanları okumanın yanında, yazmaya ve ağa kendinden bir şey katmaya yöneltti. Ağda ortaklaşa üretimlerde bulunmak ya da belirli bir amaç doğrultusunda harekete geçmek için bir araya gelen kullanıcılar kendilerine özerk iletişim alanları yarattılar. Böylece internetin iletişimi güçlendirecek ve çeşitlendirecek biçimde gelişmesini de sağladılar.

Ancak internetin bu yönde gelişimini devam ettirebilmesi için bazı koşulların devamı gereklidir. İnternet protokolleri tarafsızlığını devam ettirmelidir. Bir diğer deyişle, internet servis sağlayıcıları ve hükümetler internet üzerindeki iletişimin eşitliğine zarar vermemeli; ağ, kar getirmeyen ya da çoğunluğun görüşüne aykırı görüşlerin iletimine karşı tarafsız olmalıdır. Ayrıca teknik olarak da yenilikçi tasarımlara açık olmalıdır.

Aslında bizim sevdiğimiz internet de bu internettir. Dünyanın dört bir yanındaki İşgal Et! eylemlerinde, Wikipedia’da (ve VikiSosyalizm’de – http://www.wikisosyalizm.org), bağımsız haber sitelerinde gerçekleşen topluluk modelinin internetteki etkinliğinin bir sonucudur.

İnternette gelişen topluluk modeli, kapitalizmin rekabete, kar hırsına, dışlayıcılığa ve eşitsizliğe dayanan normları ile çelişmekte ve internetin geleceği için kapitalizmin dokusuna çok daha uygun olan tüketim modeli ile çatışmaktadır.

Kamusal ve özel çıkarların çatıştığı bu mücadele internet gibi çok katmanlıdır. Birinci katmanda www, yani içerik, yer almaktadır. Özgür yazılım ile özel mülk yazılım internetin geleceğine dair iki vizyonu temsil etmektedir. Özgür yazılım, kullanıcının teknolojiyi yaratıcı sahiplenmesine olanak vermekte, onun yaratıcı potansiyelini geliştirmektedir. Son zamanlarda birçok şirket, ürünlerini özellikle kapalı, sadece belirli bir amaç doğrultusunda kullanılmak üzere geliştirmekte, kullanıcının teknolojiyi yeniden yorumlamasının önüne geçmektedir. Dolayısıyla, özel mülk yazılıma karşı özgür yazılımı savunmak (ve kullanmak!) internetin gelecekte ne olacağına dair politik bir müdahaledir.

İkinci çatışma alanı ise daha alt katmanlarda, ağ tarafsızlığı alanındadır. Şirketler, filmlerin ve televizyon programlarının ağda önceliklendirilmesi için ABD’de yoğun bir kulis faaliyeti yürütmektedir. Eğer eğlence şirketlerinin ve internet servis sağlayıcılarının girişimleri başarılı olur ve ağ trafiği ticari faaliyetleri önceliklendirmeye başlarsa, internet tüketim modeline yönelecektir.

Kısacası, internette çetin bir mücadele söz konusudur. Ancak hangi model başarılı olursa olsun, diğer modeller de ortadan kalkmayacak ama internetin sonraki gelişiminde ikincil olacaktır. Tabi bu mücadeleyi sadece izlemek gibi bir lüksümüz yok. Solun internetle (ya da daha genel olarak bilişim teknolojileri ile) olan ilişkisini de 11. Tez’den başlayarak tartışmak gerek:

Filozoflar dünyayı yalnızca çeşitli biçimlerde yorumlamışlardır; oysa sorun onu değiştirmektir.

Sorun internetin dün ve bugün ne olduğu değil, onun yarın ne olabileceğidir. Belki herkes yazılım geliştiremez ama örgütlenerek teknolojinin tasarımına etkide bulunabilir. Gündem yaratarak, halkı teknolojinin gelişimine dair tartışmalara katarak, bu tartışmaları davalara ve boykotlara taşıyarak, yeni hukuksal düzenlemelere zorlayarak hükümetler ve şirketler, kamu yararını gözeten tasarımlar yapmaya zorlanabilir.

İnterneti özel mülk yazılımın kollarına atan, internetin açıklık ilkesini çiğneyen ve gözetimi artıran her girişim sorgulanmalıdır. Örneğin, torba torba yasalar çıkarken kişisel verilerin korunması hakkındaki yasal düzenlemenin akıbeti sorgulanabilir, toplumun daha geniş kesimlerine sorgulatılabilir. Pardus projesine ne olmuştur? Ankara Üniversitesi’nin Microsoft’la yaptığı anlaşmanın sonuçları ne olacaktır? [5]

Tüm bu konular ve sorunlar internetin geleceği konusunda ilgisiz sorularmış gibi görünebilir…

İnternet kısmen ya da tamamen sansürlenebilir ve toplulukların iletişimleri kısıtlanabilir. Fakat bu girişimlerin etkili olup olmayacağı internet kullanıcılarının yaratıcı etkinliklerine ve dolayısıyla bilişim teknolojilerinin buna ne kadar imkan verdiğine bağlıdır. Geçtiğimiz ay Hong Kong’daki gösterilerde kullanılan mesh ağlar bu duruma güzel bir örnektir [6].

İnternet, tasarımına içsel kalımlılık kaygısına rağmen doğal afetlere ya da hükümetlerin sansürüne karşı yeterince dayanıklı değildir. Çünkü kullanıcılar internete girmek için merkezi düğümlere gereksinim duyarlar. X adlı internet servis sağlayıcıya bağlanmadan internete çıkamazsınız; komşunuzla bile internet üzerinden haberleşemezsiniz. Mesh ağlarda ise iletişim merkezsiz bir ağ ile kurulur. Cihazlar kendilerini bant genişliğinin uygunluğuna ve yakınlığına göre ayarlayarak birbirleriyle haberleşebilir. Ağdaki cihazlar arasındaki iletişim dinamik bir rota üzerinde gerçekleşir. Dolayısıyla, ağdaki tüm cihazları ortadan kaldırmadıkça bir mesh ağı kapatmak mümkün değildir. Bu nedenle mesh ağlardan oluşan internet doğal ya da politik felaketlere karşı normal internetten daha sağlamdır.

Mesh ağlar, felaket senaryoları dışında özellikle fakir ve yetersiz hizmet alan bölgeler için de uygulanabilir. Maddi gücü yetersiz olanlar için ücretsiz bir iletişim ağı sağlayabilir. Mesh ağlar, aynı zamanda internetin ilk günlerindeki saf haline dönüştür. Mesh ağı, internetten görülemeyeceği için iletişimi gözetlemek için doğrudan ağa dahil olunması gerekir. Ayrıca merkezi bir otorite olmadığından kişilerin kimliklerini tespit son derece zordur (De Filippi, 2014).

Mısır’da, İran’da ve son olarak Hong Kong’da sansüre karşı topluluk içi iletişimi devam ettirebilmek için mesh ağlar kullanıldı. Fakat De Filippi mesh ağların öneminin yalnızca doğal felaketlerle ve sansürle sınırlı olmadığını düşünmektedir. Grup içi iletişim için merkezi noktalara ihtiyaç duymamasının yanında merkezi bir otorite de yoktur. Topluluk tarafından örgütlenip topluluğun ihtiyaçları doğrultusunda çalışır. Mesh ağlarla, birbirinden bağımsız, çok sayıda internetimiz olabilir [7].

Tabi teknik olarak henüz internet kadar güçlü ve yeterli değildir. Ama mesh ağların yaygınlaşmasının önünde tahmin edebileceğiniz gibi iki büyük engel vardır: hükümetler ve şirketler. Hükümetler kontrol edemeyecekleri, şirketler (internet servis sağlayıcılar ve telefon operatörleri) de abonelik üzerine kurulu iş modelleri geçersizleşeceği için mesh ağlara sıcak bakmamaktadır.

Ama en son Hong Kong’daki gösterilerde olduğu gibi kullanıcılar zor durumda kaldıklarına mesh ağlarına yöneliyorlar. Hong Kong’daki göstericiler, kendi aralarındaki iletişimi hem iPhone’da hem de Android’de çalışan FireChat uygulaması ile sağladılar. Fakat mesh ağlar deyince ilk akla gelen proje olan Serval Projesi [8] (http://www.servalproject.org/), iPhone yerine neden Android telefonları öncelikli olarak gördüğünü açıklarken iPhone’lar için yazılım geliştirirken yaşanan kısıtlılıklara dikkat çekmektedir [9]:

  • iOS’daki uygulama geliştirme lisansları kısıtlayıcıdır.
  • Uygulama dağıtma seçenekleri kısıtlıdır.
  • Apple kendi iş modelini ya da iş ortakların rahatsız eden girişimlere karşı düşmanca davranmaktadır.

Bu nedenle, hem iPhone’u hem de İnternet’i aynı anda eleştiremezsiniz. Nitekim iPhone’da FireChat kullanmak da diğer internet uygulamaları gibi merkezi bir otoritenin (Apple’ın) onayına bağlıdır. Acaba Amerikan çıkarlarına aykırı bir gösteride de iPhone kullanılabilecek midir? Mesh ağlarının sunduğu iletişim özgürlüğü Apple’ın inisiyatifindedir.

Tam tersini de, özgür yazılım ile özel mülk yazılım arasındaki çatışmada sessiz kalıp, internette sansüre ve ticarileşmeye hayır diyemezsiniz. Çünkü internetin geleceğini özgür yazılım ve özel mülk yazılım arasındaki bu irili ufaklı çatışmalar belirleyecek: Biz interneti bir iletişim alanı olarak görüp geliştirmek isteyeceğiz, firmalarda bizim bu girişimlerimizi engelleyip onu büyük bir alışveriş merkezine çevirmeye çalışacaklar.

İnternet için henüz son söz söylenmedi… Mücadeleye devam!

 

Kaynaklar

De Filippi, P. (2014). It’s Time to Take Mesh Networks Seriously (And Not Just for the Reasons You Think). Wired, February.

Feenberg, A., Bakardjieva, M. (2004). Consumers or citizens? The online community debate. na.

Feenberg, A. (2012). Introduction. In (Re) Inventing The Internet (s. 3-17). SensePublishers.

Notlar:

[1] http://www.yenisafak.com.tr/teknoloji/erdogandan-iphone-6-elestirisi-688641, son erişim 18/10/2014

[2] http://www.hurriyet.com.tr/dunya/27323343.asp, son erişim 18/10/2014

[3] http://www.bbc.com/news/technology-29505103, son erişim 18/10/2014

[4] http://www.ntvmsnbc.com/id/25542836/, son erişim 18/10/2014

[5] http://btdunyasi.net/70-bin-ogrenci-microsoft-office-365i-bedava-kullanacak/, son erişim 18/10/2014

[6]http://www.npr.org/blogs/alltechconsidered/2014/09/29/352476454/how-hong-kong-protesters-are-connecting-without-cell-or-wi-fi-networks, son erişim 18/10/2014

[7]http://www.wired.com/2014/01/its-time-to-take-mesh-networks-seriously-and-not-just-for-the-reasons-you-think/, son erişim 18/10/2014

[8]http://en.wikipedia.org/wiki/Serval_project, son erişim 18/10/2014

[9]http://developer.servalproject.org/dokuwiki/doku.php?id=content:tech:serval_mesh_for_iphone, son erişim 18/10/2014

27 Kasım 2014

Posted In: Erişim Hakkı, Fikri Mülkiyet, Genel, Gözetim, internet, mesh, Özgür yazılım, sansür, sosyal ağlar

Linux Kernel Internship

Last month I've applied Gnome Outreach Program for Women and sent patches for Linux Kernel. I've applied it because wanted to learn low level things. I also really like computer design and architecture topics. Actually, I have not enough knowledge about them but like to learn them.

Linux Kernel Community accepted to me as an intern. I'll study on Khugepaged swap readahead project. Working with Linux Kernel team will be great experience for me. They really want to help kernel newbies :).

Actually, studying on Linux Kernel needs a lot reading. Just for writing a few code lines needs to read one chapter from one book, a few blog posts about topic and ask something to developers :).

Nowadays, I've started to read about memory management issues like TLB, Huge Pages, Page Fault from one operating system book and also examine do_page_fault() function.

26 Kasım 2014

Posted In: Gezegen, Gnome, internship, kernel, linux, opw

Google Hiring Process

This story started 4 months ago. I've got an email from a Google recruiter. She wanted to do a phone conversation with me. I was very happy to hear this and accepted the conversation immediately.

First phone conversation was initial phone interview, she asked me basic questions about data structures, bitwise operations, linux commands etc. But I think the questions were not basic :p I passed initial phone interview and preferred Site Reliability System Engineer position for myself. I took first round telephone interview with an Google engineer and used Google Doc for coding questions.

Before the first round to prepare myself I was studying algorithms, data structures, network, linux commands, troubleshooting. Following links were really helpful for me:

Geeks For GeeksGlassadorCareerupCracking Code InterviewsSystem DesignDevops Interview Questions.

I passed first round, the engineer said to me you did great most of this interview! I was really happy to hear this and couldn't believe what I heard :) The whole process was very excited, funny and nice for me.

We moved the process for second phone interview. Again I studied for same things and used Google Doc for coding questions. My second interview has only one question, when I replied the question, interviewer generated new questions which was derived from same question. Second round interview was not very good but my recruiter called me and said you passed it, we would like to invite you for onsite interview at one Google office, Google will pay your all expenses. I preferred Dublin office of Google which is headquarters for the Europe offices.

I prepared to practising English myself, and whole summer went English speaking courses, because in my country have no other chance to practising English unfortunately :(

Actually, my English is not very good and when talked with employees of Google I feel really excited so I couldn't talk much so many times :) however during the onsite interviews I discussed a lot on questions because it is my job, but for usual questions how are you?, are you excited?, do you have question? etc. this kind of questions I could talk less :) Engineers of Google are very understanding people to my English. Also in Google Dublin office, people coming from 65 different countries and there are 45 different languages.

Onsite interview have 5 different steps. For SRE (Site Reliability Engineer) position, I've got following steps and each step has 45 minutes with 5 different interviewers. Onsite interview is last round for Google hiring process.

1) ​​Non Abstract Large System Design
2) Troubleshooting / Problem Solving
3) ​Practical Coding - ​Ruby​
4) ​Design/Coding
5) Unix/ Linux ​Systems​

Onsite interview questions were not expected things for me :(. I read a lot of blog posts, they say the questions are very expected, but I think some of them really expected things however most of them were not. I also solved a lot of onsite interview questions before mine.

I couldn't pass the onsite interview however this was really great experience for me. The whole process was very exciting, every steps made me very happy and excited :).  I also met a few Google engineers and my recruiters. They are really helpful and friendly people.

Dublin is not big city so there is no a lot of people, it is not crowded. It was very rainy on my interview day. I stayed two nights in Dublin. After my interview I had time to discover the city. There is river which called as River Liffey in Dublin. It is like a map to find your road :p You can follow along the river so can find your hotel very quickly :).

I'm very happy to met with Google engineers. This was very good experience for me. I'm only 22 years old I can retry it, thanks a lot to Google.

22 Kasım 2014

Posted In: Gezegen, google, hiring process, interview

Haydi sifreleyelim girisimi (let’s encrypt initiative)

EFF bugun internetin gelecegini degistirme potansiyeli olan let's encrypt adini verdikleri projeyi duyurdu. Mozilla, Cisco, Akamai gibi devlerin yani sira IdenTrust ve Michigan Universitesi arastirmacilarinin da katkilariyla olusturduklari yeni bir sertifika otoritesi olan let's encrypt, web'in http'den https'ye gecisi onunde kalan son engelleri de kaldirmayi amacliyor. Bu yazida https'nin http'ye gore artilarini siralamaktansa let's encrypt otoritesini, girisimin kurmayi planladigi sistemi ve su anda gelistirmekte olduklari ACME protokolunu anlatacagim.

Internet guvenligi arastirma grubu, ISRG, ismiyle yeni olusturulan ve kar amaci gutmeyen bir organizasyon tarafindan isletilecek let's encrypt sertifika otoritesinin hangi problemi cozmeye calistigini aciklayarak baslamak yerinde olacaktir diye dusunuyorum. SSL/TLS'in genis capta uygulanabilmesinin onundeki en buyuk engellerden en onemlileri kurulum karmasikligi, burokrasi ve sertifikalarin yuksek ucretleri olarak goruluyor. 2015 yazindan itibaren ucretsiz olarak sertifika dagitmaya baslayacak olan yeni otoritemiz su siralar tek bir komut calistirilarak, hazirda sunulmakta olan sitelerin alan adi dogrulamasini yaptiktan sonra https'ye gecirilmesi islemini yapacak bir istemci yazilimi ve bu yazilimin insa edilerken temel alindigi protokol uzerinde calisiyor. Let's encrypt bu surecte gozetecegi ana prensipleri ise soyle siraliyor;

Bedelsiz: Alan adi sahipleri kontrol ettikleri alanlar icin hicbir ucret odemeden sertifika sahibi olabilecekler

Otomatik: Sertifika alim sureci ve yenilenmesi ve sunucuda konfigure edilmesi gibi islemler tamamen otomatiklestirilerek minimum operator mudahalesi gerektirecek

Guvenli: Let's encrypt modern guvenlik tekniklerinin ve alandaki en iyi uygulamalarin implemente edilebilecegi bir platform olacak

Seffaf: Verilen ya da gecersiz kilinan tum sertifikalar incelemek isteyen herkese acik olacak

Acik: Gelistirilen protokol herkese acik bir standart olacak, gelistirilen yazilimlar ise elverdigince acik kaynak olarak sunulacak

Katilimci: Tek bir organizasyonun kontrolunde olmaktansa her acik standartta oldugu uzere topluluktan katilimcilarin fayda saglayacagi tumlesik bir girisim olmayi amaclayacak

Gelelim nasil calistigina. Altyapi ve istemci yazilimi tamamlandiginda kendi ifadeleriyle

sudo apt-get install lets-encrypt  
sudo lets-encrypt ornek.com  

komutlarini calistirmak tum ayarlari ve sertifika surecini halletmek icin yeterli olacak. Peki arkaplanda neler oluyor? Aslinda bunun icin istemci yazilimin ne yaptigina bakmadan once ACME protokolune bakmakta fayda var. Taslak halindeki RFC'ye gore genel hatlariyla protokol soyle.

Istemci yazilimi operatore hangi alan adlari icin sertifika istedigini soracak. Bu islemin ardindan sertifika otoritelerinin bir listesi gelecek. Eger secilen otorite ucretsiz sertifika saglayan bir otorite degilse odeme bilgisi bu asamada istenecek. Daha sonra yazilim operatore kisa bir sure icinde sertifikanin verilecegini bildirecek. Arkaplanda sunucu, sertifika otoritesi ile ACME kullanarak operatorun belirttigi alan adlari icin sertifika isteginde bulunacak. Sertifika otoritesinin verilen sertifikanin tipine gore belirledigi gereksinimler yerine getirildiginde verilen sertifika otomatik olarak indirilecek ve web sunucu sertifikayi kullanacak sekilde yapilandirilacak. Tercihen operatore e-posta, sms vb. gibi bir yontemle haber verilecek. Normal web hizmeti surecinde web sunucu sertifika otoritesi ile gerektigi taktirde konusarak OCSP (cevrimici sertifika durum protokolu) cevaplari, sertifika listeleri gibi bilgileri almaya devam ederek sorunsuz bir web sunma isinin yururlugunu saglamaya devam edecek.

Burada araya girip bir iki konuya acikliga kavusturayim. Yukarida web sunucu olarak bahsedilse de e-posta, xmpp vs. gibi sertifika kullanabileceginiz her hizmette ACME protokolunu ve bu protokol uzerinden calisan istemciyi kullanabileceksiniz. Su asamada organizasyon dogrulamasi(organization validation) ya da kapsamli dogrulama(extended validation) surecleri nasil isleyecek cok net olmasa da alan adi dogrulama icin(domain validation) bir sorun yok gibi gozukuyor. Protokole doneyim.

Standardimizda uc adet anahtar/anahtar cifti tanimi bulunuyor.

Ozne acik anahtari (subject public key): Sertifikaya konu olan alanlar icin dahil edilecek acik anahtar

Yetkilendirilmis anahtar cifti (authorized key pair): Sertifika otoritesinin herhangi bir kimligin yonettigi/yonetebilecegi sertifikalar icin iletisimde kullanacagi anahtar cifti. Bu cift birden fazla kimlik icin kullanilabiliyor.

Sifirlama anahtari (recovery token): Diger anahtarlarin ya da anahtar ciftlerinin kaybedilmesi durumunda sertifika otoritesine kimlik kanitlamak icin kullanilabilecek gizli anahtar

Butun iletisim https uzerinden json ile saglaniyor. Kimlikler ACME'de anahtar ciftleri ile ifade ediliyor. Bir alan adi icin istek yapilmadan once gecerli bir anahtar ciftinin ozel anahtarinin o alan adini kontrol eden tarafindan sahipliginin gosterilmesi gerekiyor. Bu kisim bildigimiz acik anahtarli sifrelemenin aynisi oldugundan uzerinde cok durmaya gerek yok. Alan adinin ya bir DNS kaydi ile ya da sunulan bir dosya ile bir ozel anahtar tarafindan kontrol edildigi kanitlaniyor. Sertifika otoritesi bu kanitlama basarili olursa basarili mesaji ve sifirlama anahtari donuyor istemciye.

Kimlik kanitlama isleminin ardindan istemci, belirtilen alan icin bir sertifika imzalama istegi olusturuyor(CSR) ve bu istegi ozel anahtari ile imzalayip sunucuya gonderiyor. Sunucu gelen istegin daha once dogruladigi anahtar ciftine ait olduguna emin olduktan sonra sertifikayi olusturuyor ve istemciye gonderiyor. Bu cevapta sertifika yenilemenin tekrar bir dogrulama gerektirmedigi durumlarda, istemci tarafindan yenileme icin kullanilabilecek adres de gonderilebiliyor. Sertifikanin iptali icin istemci basitce, ozel anahtariyla imzaladigi iptal istemini sunucuya gonderiyor ve sunucu bu istegi aldiginda sertifikayi iptal ediyor. Istemci ya da sunucu yazacaklar icin taslak standardin burada atladigim teknik detaylarina yukarida paylastigim protokol adresinden ulasmak mumkun.

Sistem 100 metre yukaridan bakildiginda aciklamaya calistigim sekilde isliyor. Ucretsiz sertifikalarin edinilebilmesine olanak taniyacagi ve TLS implementasyonu onundeki teknik engelleri kaldirma potansiyeli oldugu icin interneti degistirebilecek bir proje olarak goruyor ve heyecanlaniyorum. Umarim Postfix, Nginx, ejabberd gibi projeler de ACME'yi ve dolayisiyla let's encrypt sertifika otoritesini otomatik olarak kullanabilmek ve yapilandirabilmek icin gereken adimlari en kisa surede atarlar. Bu sayede gorece daha guvenli bir internet deneyimi icin gereken en temel adimlardan birini atmis oluruz.

19 Kasım 2014

Posted In: eff, Gezegen, let's encrypt, SSL, TLS

Doctrine 2 ile Optimistic Locking

Yoğun editör işlemlerinin olduğu projelerde aynı yazıyı içeriği güncelleme problemleri ile sıkça karşılaşılır.

Örnek senaryo;

  • 1. editör 1. yazıyı güncellemek için açtı.
  • 2. editör 1. yazıyı güncellemek için açtı.
  • 1. editör 1. yazıyı güncelledi.
  • 2. editör 1. yazıyı güncelledi(!).

Son değişikliği 2. editör yaptığı için 1. editörün yaptığı değişiklikler silindi. Bunu önlemek için 2. editöre “Senden önce 1. editör bu yazıyı düzenledi. Önce onun değişikliklerine bakmalısın.” demek gerek.

Peki bu uyarı sistemini ne ile kuracağız?
Optimistic Locking yöntemi ile.

Kısaca bu yöntemi şu şekilde çalışır:

Tablo ismimiz Post olsun. Post tablosuna “version” isminde bir sütun daha ekleyeceğiz. İlk insert işleminde version sütununa 1 yazılır. Her yazı güncellemesinde version sütunundaki sayı 1 arttırılır.

Kullanıcı içeriği güncellediğinde versiyon sayısı güncellemeden önceki sayı ile aynı değilse içerik daha önce birileri tarafından güncellenmiştir.

PHP’de bu işlemleri araya herhangi bir ORM koymadan halledebilirsiniz. Ancak sizin yerinize Doctrine 2 versiyonlama işlemini destekliyor.

Yapmanız gereken Post entity’nize bir @Version annotation’ı eklemeniz.

Örnek olarak hazırladığım Post ismindeki entity’e buraya tıklayarak ulaşabilirsiniz.

Entity sınıfında gerekli versiyonlama için düzenlemeyi yaptık.

Bu Post entity sınıfını kullanarak yazdığım örnek bir Symfony 2 controller’ı da şu şekilde:

namespace Acme\BlogBundle\Controller;

use Acme\BlogBundle\Entity\Post;
use Acme\BlogBundle\Form\PostType;
use Doctrine\DBAL\LockMode;
use Doctrine\ORM\OptimisticLockException;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template;
use Symfony\Component\HttpFoundation\Request;

class DefaultController extends Controller
{
    /**
     * @Route("/post/{id}")
     * @Template()
     */
    public function showAction($id)
    {
        $em = $this->get('doctrine')->getManager();
        $entity = $em->find('Acme\BlogBundle\Entity\Post', $id, LockMode::OPTIMISTIC);
        $form = $this->createForm(new PostType(), $entity, ['action' => $this->generateUrl('update_action')]);
        return $this->render('AcmeBlogBundle:Default:show.html.twig', ['form' => $form->createView()]);

    }

    /**
     * @Route("/update", name="update_action")
     * @Method({"POST"})
     */
    public function updateAction(Request $request) {

        $post = new Post();

        $form = $this->createForm(new PostType(), $post);

        $form->handleRequest($request);

        if($form->isValid()) {
            $formData = $form->getData();
            $post->setId($formData->getId());
            $post->setTitle($formData->getTitle());
            $post->setContent($formData->getContent());
            $post->setVersion($formData->getVersion());

            try {
                $em = $this->getDoctrine()->getManager();
                $em->merge($post);
                $em->flush();
            } catch(OptimisticLockException $e) {
                return $this->render('AcmeBlogBundle:Default:locking.html.twig');
            }

            return $this->render('AcmeBlogBundle:Default:success.html.twig');

        }
            return $this->render('AcmeBlogBundle:Default:error.html.twig');

    }
}

22. satırda Optimistic Locking kullanarak find işlemini yapıyoruz. 51. satırda OptimisticLockException ismindeki Exception için bir kural yazılı. Doctrine 2 bizim yerimize version sütununu kontrol ediyor, eğer değer aynı değilse OptimisticLockException isminde bir Exception fırlatıyor.

Örneğin; /post/5 yolunu iki ayrı browser tabında açıp, ikisinde de güncelleme yapılsın. İlk güncelleme çalışacaktır ve 5 numaralı satırın version sütununu 2‘ye yükselecektir. İkinci tabdan güncelleme yapıldığında orada version bilgisi 1 olarak kaldığı için OptimisticLockException‘ı fırlayacaktır.

Bazı kaynaklarda versiyonlama sütunlarını date time veya timestamp olarak da tutulmasından bahsedilebilir. Ancak olası zaman kaymaları için bu yöntem önerilmez.

Ayrıca Bkz.: Dirty read

Not: Symfony 2’de Doctrine 2 varsayılan olarak geldiği için Symfony 2 controller örneği verdim. Doctrine 2’yi başka frameworklerde de kullanabilirsiniz.

14 Kasım 2014

Posted In: Genel, Gezegen

PHP – Identity Map Pattern

$user1 = User::find(1);
$user  = new User();
$user1 = $user->find(1);

Bunlar ve buna benzer kullanımlar PHP içerisinde sıkça görebileceğiniz kullanıcı çekme yöntemleridir. User sınıfındaki find() metotu size bir UserRepository (ismi salladım) nesnesi döndürür oradan işlem yaparsınız.

Örneğin; Runtime’da iki alakasız yerde 1 numaralı kullanıcının veritabanındaki bilgilerine ihtiyacınız var.

Birinci yerde User::find(1) yaptınız ve SELECT sorgusu çalıştırdınız. Kodun farklı bir noktasında tekrar User::find(1) yaptınız ve tekrar SELECT sorgusu işlendi.

Ama daha önce 1 numaralı kullanıcı veritabanından çekilmişti. Tekrar SELECT yapmaya gerek var mı?

veya…

X metotu içinde User::find(1) yaptınız kullanıcıyı çektiniz ve kullanıcı adı Ali.

Sonra Y metotunda tekrar User::find(1) yaptınız. Ama Y metotunun içinde şöyle bir if koşulu var: “Eğer id 1 ise kullanıcı adını Veli yap”.

Y metotundaki kullanıcı adı Veli oldu. Ama geri X metotuna döndüğümde kullanıcı adı hâlen Ali kaldı.

Böyle birçok farklı senaryo düşünülebilir.

Buradaki temel problem her find yapıldığında yeni bir UserRepository objesinin geriye dönmesinden kaynaklanıyor.

Sistem geneli 1 numaralı kullanıcı için hep aynı nesneyi kullansa tekrar SELECT‘e gerek kalmayacak ve bir metotta kullanıcı adı setlendiğinde başka metotta da bu görülebilecek.

Peki bu nasıl sağlanacak? Identity Map Pattern ile.

Runtime’da objeleri cacheleyeceğiz.

User::find(1) işlemi için metotu hazırlayalım.

User.php

class User {
    public static function find($id) {
        return (new UserMapper)->init($id);
    }
}

Kullanıcı bilgilerinin bulunduğu UserRepository ile User sınıfının arasındaki bağlantıyı sağlayacak Mapper.

UserMapper.php

class UserMapper {
    
    private static $object;
    
    public function init($id) {
        if( ! isset(self::$object[$id])) {
            self::$object[$id] = (new UserRepository)->fetch($id);
        }

        return self::$object[$id];
        
    }
    
}

Son olarak da kullanıcı bilgilerini barındıran UserRepository sınıfı

UserRepository.php

class UserRepository {

    public $users = [['name' => 'Ali'], ['name' => 'Veli']];

    private $name;

    public function fetch($id) {
        if( ! isset($this->users[$id])) {
            throw new InvalidArgumentException;
        }

        $userRepository = new self; 
        $userRepository->setName($this->users[$id]['name']);

        return $userRepository;
    }

    public function getName() {
        return $this->name;
    }

    public function setName($name) {
        $this->name = $name;
    }
}

Burada bir de DAO işlemleri için ekstra sınıflar gerekiyor. Ancak örnek olması için veritabanı olarak bir basit array kullandım.

Örnek işleme bakalım:

test.php


$user1 = User::find(1);
$user2 = User::find(1);

$user1->setName('Emre');
echo $user2->getName(); // $user2 objesi de Emre oldu

UserMapper sınıfında nesneler cachelenmeseydi ve her defasında return (new UserRepository)->fetch($id); yapılmış olsaydı $user2 nesnesinin getName metotu Veli sonucunu döndürecekti.

Ayrıca cachelendiği için UserRepository sınıfındaki fetch metotu da 1 defa çalıştı. Buradaki isset işlemini SELECT sorgusu olarak düşünebilirsiniz.

Ayrıca Bkz.: Optimistic Offline Lock

9 Kasım 2014

Posted In: Genel, Gezegen

Şifreli e-posta neden yaygınlaşmıyor?

encrypted-emailSayısal iletişimde e-posta önemli servislerden birisi. Şifreleme kullanılmadan yapılan e-posta trafiği, olası kritik verinin açık ve erişilebilir olarak İnternet ortamından geçmesi anlamına geliyor.

Günümüzde e-posta şifreleme yöntemleri karmaşık yapıya sahip ve tek taraflı e-posta şifreleme yöntemi bulunmuyor. Sayısal kimlik tabanlı şifreleme (IBE – Identity Based Encryption) günümüzde ideale en yakın çözümlerden. IBE’de şifreleme, e-postayı yazan ve okuyan taraflara en yakın seviyede başlatılır ve bitirilir. Yasal düzenlemeler ile nitelikli sayısal kimliklere, veri bütünlüğünü kanıtlama, kimlik doğrulama ve inkar edilemezlik özellikleri kazandırılmıştır.

E-posta şifreleme yöntemlerinin tamamı PKI (public key infrastructure) altyapısına dayanmaktadır. Tam bir PKI uygulaması, dijital sertifikaların dağıtılması ve yönetilmesini gerektirir. PKI masraflı ve bilgi birikimi gerektiren bir uygulamadır. PKI altyapısı kullanılarak yapılan e-posta şifrelemede açık anahtarların (public key) güvenli şekilde dağıtılması yapının problemlerindendir. Şifreli e-posta gönderilmek istendiğinde, karşı tarafın açık anahtarının güvenli şekilde önceden temin edilmiş olması gerekliliği, yapının en zayıf noktasıdır. Sayısal kimlik tabanlı e-posta şifreleme bu nedenlerden dolayı yaygınlaşamamaktadır.

Uygulanabilirliği yüksek ve son kullanıcı bilinci gerektirmeyen şifreleme alternatifi, e-posta sunucuları arasında TLS kullanılmasına dayanır. Fakat RFC 2487e göre, İnternet’e açık sunucular sadece TLS bağlantıları kabul edilecek şekilde ayarlanmamalıdır.

DNSSEC’in kullanım alanlarından birisi de güvenli açık anahtar dağıtımı olacak. DNSSEC ile ilgili yazım ilginizi çekebilir, http://ozcan.com/blog/dnssec-nedir/ .

Hamdi ÖZCAN – ozcan.com

6 Kasım 2014

Posted In: açık anahtar altyapısı, dnssec, e-mail, eposta, IBE, ID-based encryption, kripto, lkd, pki, RFC 2487, sayısal kimlik tabanlı şifreleme, şifreleme, teknik, TLS, tr

Şifreli e-posta neden yaygınlaşmıyor?

encrypted-emailSayısal iletişimde e-posta önemli servislerden birisi. Şifreleme kullanılmadan yapılan e-posta trafiği, olası kritik verinin açık ve erişilebilir olarak İnternet ortamından geçmesi anlamına geliyor.

Günümüzde e-posta şifreleme yöntemleri karmaşık yapıya sahip ve tek taraflı e-posta şifreleme yöntemi bulunmuyor. Sayısal kimlik tabanlı şifreleme (IBE – Identity Based Encryption) günümüzde ideale en yakın çözümlerden. IBE’de şifreleme, e-postayı yazan ve okuyan taraflara en yakın seviyede başlatılır ve bitirilir. Yasal düzenlemeler ile nitelikli sayısal kimliklere, veri bütünlüğünü kanıtlama, kimlik doğrulama ve inkar edilemezlik özellikleri kazandırılmıştır.

E-posta şifreleme yöntemlerinin tamamı PKI (public key infrastructure) altyapısına dayanmaktadır. Tam bir PKI uygulaması, dijital sertifikaların dağıtılması ve yönetilmesini gerektirir. PKI masraflı ve bilgi birikimi gerektiren bir uygulamadır. PKI altyapısı kullanılarak yapılan e-posta şifrelemede açık anahtarların (public key) güvenli şekilde dağıtılması yapının problemlerindendir. Şifreli e-posta gönderilmek istendiğinde, karşı tarafın açık anahtarının güvenli şekilde önceden temin edilmiş olması gerekliliği, yapının en zayıf noktasıdır. Sayısal kimlik tabanlı e-posta şifreleme bu nedenlerden dolayı yaygınlaşamamaktadır.

Uygulanabilirliği yüksek ve son kullanıcı bilinci gerektirmeyen şifreleme alternatifi, e-posta sunucuları arasında TLS kullanılmasına dayanır. Fakat RFC 2487e göre, İnternet’e açık sunucular sadece TLS bağlantıları kabul edilecek şekilde ayarlanmamalıdır.

DNSSEC’in kullanım alanlarından birisi de güvenli açık anahtar dağıtımı olacak. DNSSEC ile ilgili yazım ilginizi çekebilir, /blog/dnssec-nedir/ .

Hamdi ÖZCAN – ozcan.com

6 Kasım 2014

Posted In: açık anahtar altyapısı, dnssec, e-mail, eposta, IBE, ID-based encryption, kripto, lkd, pki, RFC 2487, sayısal kimlik tabanlı şifreleme, şifreleme, teknik, TLS, tr

Teknolojinin Kadınları Etkinliği Sunumum

Geçtiğimiz günlerde Kadın Yazılımcı topluluğu ile birlikte İstanbul Hackerspace'de Ada Lovelace Day ve Grace Hopper Celebration'ı Türkiye'de de kutlamak için bir etkinlik düzenledik, bu etkinlik için ben de bir sunum hazırladım.

Etkinlik ile ilgili Cansu Uludağ'ın değerlendirme yazısı hayli kapsamlı olmuş, okumanızı tavsiye ederim. Hem vesileyle benim bu blog yazısında (zaman sıkıntısından) bahsedemediğim diğer arkadaşlarımın şahane sunumlarını da okumuş olursunuz.

Bu blog yazısında, yoğunluktan ertelediğim bir işi yapmaya hazırlanıyorum. Etkinlikte yaptığım, hazırladığım sunumu paylaşıyorum. 

 Dünyada yazılım, bilişim ve teknoloji alanında kadınları teşvik etme amacıyla düzenlenen etkinlikler, programlar ve bu konuda kadınlara fon ayıran vakıflar hakkında bilgi verdiğim sunumuma buradan ulaşabilirsiniz.

Çoğunlukla kadınların yer aldığı özgür yazılım, açık kaynak projeleri, organizasyonlarının yer aldığı (içerisinde yer almamla bildiğim, takip ettiklerim nedeniyle) bu sunumu peyderpey de olsa güncellemek yapılacaklar listeme girdi bile! :)
                    

4 Kasım 2014

Posted In: ada lovelace, bilgisayar bilimleri, burslar, computer science, GLFS, grace hopper, kadın, Özgür yazılım, scholarship, software, teknoloji, women, yazılım

Twitter Auto Publish Powered By : XYZScripts.com