Bölünmüş Vt Hakkında

1 2 3
01/11/2018, 12:07

notrino

Merhabalar,

Bildiğiniz üzere, bir VT bölündüğünde kullanıcı PC sindeki form ve sorgularla birlikte, yanında ok işareti olan tablo sembolü görünüyor. Kullanıcı bu tabloyu silse de sadece bağlantıyı silmiş oluyor, orjinal veritabanındaki tablo korunmuş oluyor. Ancak kullanıcı, bu ok işaretli tabloyu tıklayıp içine girdiğinde istediği kaydı silebiliyor. Yani tabloyu silmese bile istediği tüm kayıtları silebiliyor. O zaman veri güvenliği tehlikede değil mi?
01/11/2018, 16:04

Allback

(01/11/2018, 12:07)notrino yazdı: Merhabalar,

Bildiğiniz üzere, bir VT bölündüğünde kullanıcı PC sindeki form ve sorgularla birlikte, yanında ok işareti olan tablo sembolü görünüyor. Kullanıcı bu tabloyu silse de sadece bağlantıyı silmiş oluyor, orjinal veritabanındaki tablo korunmuş oluyor. Ancak kullanıcı, bu ok işaretli tabloyu tıklayıp içine girdiğinde istediği kaydı silebiliyor. Yani tabloyu silmese bile istediği tüm kayıtları silebiliyor. O zaman veri güvenliği tehlikede değil mi?

Verileriniz tabii ki tehlikede ama bunu minimize etmenin yolları var.

Bunlardan en önemlileri verilerinizin belirli periyotlar ile yedeklerini almak ve otomatik aldırmak.
Diğer bir konu da kullanıcıların tablolara direk erişimini engellemek için, tüm işlemlerini form üzerinden yapacak şekilde tasarım yapmak. (pencereleri gizlemek ve bir tane ana form yapıp, bütün formlara erişimi bu ana form üzerinden yaptırmak gibi)
01/11/2018, 20:26

notrino

(01/11/2018, 16:04)Allback yazdı:
(01/11/2018, 12:07)notrino yazdı: Merhabalar,

Bildiğiniz üzere, bir VT bölündüğünde kullanıcı PC sindeki form ve sorgularla birlikte, yanında ok işareti olan tablo sembolü görünüyor. Kullanıcı bu tabloyu silse de sadece bağlantıyı silmiş oluyor, orjinal veritabanındaki tablo korunmuş oluyor. Ancak kullanıcı, bu ok işaretli tabloyu tıklayıp içine girdiğinde istediği kaydı silebiliyor. Yani tabloyu silmese bile istediği tüm kayıtları silebiliyor. O zaman veri güvenliği tehlikede değil mi?

Verileriniz tabii ki tehlikede ama bunu minimize etmenin yolları var.

Bunlardan en önemlileri verilerinizin belirli periyotlar ile yedeklerini almak ve otomatik aldırmak.
Diğer bir konu da kullanıcıların tablolara direk erişimini engellemek için, tüm işlemlerini form üzerinden yapacak şekilde tasarım yapmak. (pencereleri gizlemek ve bir tane ana form yapıp, bütün formlara erişimi bu ana form üzerinden yaptırmak gibi)

Evet, dedikleriniz doğru. Ama bölünmüş, sonra bir güzel mde yapılmış bir veritabanında, form-rapor gibi nesneler silinemez, tasarım formatında açılamaz, VB kodlara ulaşılamazken (yani form-rapor-kod güvenliği sağlanmışken) aynı güvenliğin "ok işaretli tablo" sembolü için sağlanamamış olması ne tuhaftır. Bu o kadar zor bir şey mi ki bunu yapamamış Access? Sırf tablo içindeki verileri korumak adına Access penceresi gizleme, Shift ile açmayı gizleme gibi, VT tasarlayan kişiye bir sürü takla attırmanın ne alemi var anlayamıyorum? Veritabanının orjinalini elinde tutan tasarımcı her türlü yetkiye sahip olsun tabi de masaüstünde sadece mde bulunan kullanıcılara ne diye tabloya erişim imkanı sunmuşlar bu anlaşılır değil..Bir veritabanı mde olduysa tablodaki ham verilere müdalehe de disable olmalı değil mi? Yanlış mıyım?
01/11/2018, 22:20

Allback

(01/11/2018, 20:26)notrino yazdı:
(01/11/2018, 16:04)Allback yazdı:
(01/11/2018, 12:07)notrino yazdı: Merhabalar,

Bildiğiniz üzere, bir VT bölündüğünde kullanıcı PC sindeki form ve sorgularla birlikte, yanında ok işareti olan tablo sembolü görünüyor. Kullanıcı bu tabloyu silse de sadece bağlantıyı silmiş oluyor, orjinal veritabanındaki tablo korunmuş oluyor. Ancak kullanıcı, bu ok işaretli tabloyu tıklayıp içine girdiğinde istediği kaydı silebiliyor. Yani tabloyu silmese bile istediği tüm kayıtları silebiliyor. O zaman veri güvenliği tehlikede değil mi?

Verileriniz tabii ki tehlikede ama bunu minimize etmenin yolları var.

Bunlardan en önemlileri verilerinizin belirli periyotlar ile yedeklerini almak ve otomatik aldırmak.
Diğer bir konu da kullanıcıların tablolara direk erişimini engellemek için, tüm işlemlerini form üzerinden yapacak şekilde tasarım yapmak. (pencereleri gizlemek ve bir tane ana form yapıp, bütün formlara erişimi bu ana form üzerinden yaptırmak gibi)

Evet, dedikleriniz doğru. Ama bölünmüş, sonra bir güzel mde yapılmış bir veritabanında, form-rapor gibi nesneler silinemez, tasarım formatında açılamaz, VB kodlara ulaşılamazken (yani form-rapor-kod güvenliği sağlanmışken) aynı güvenliğin "ok işaretli tablo" sembolü için sağlanamamış olması ne tuhaftır. Bu o kadar zor bir şey mi ki bunu yapamamış Access? Sırf tablo içindeki verileri korumak adına Access penceresi gizleme, Shift ile açmayı gizleme gibi, VT tasarlayan kişiye bir sürü takla attırmanın ne alemi var anlayamıyorum? Veritabanının orjinalini elinde tutan tasarımcı her türlü yetkiye sahip olsun tabi de masaüstünde sadece mde bulunan kullanıcılara ne diye tabloya erişim imkanı sunmuşlar bu anlaşılır değil..Bir veritabanı mde olduysa tablodaki ham verilere müdalehe de disable olmalı değil mi? Yanlış mıyım?

Bu sorunuzun muhattabı sanırım Microsoft
01/11/2018, 22:32

notrino

(01/11/2018, 22:20)Allback yazdı:
(01/11/2018, 20:26)notrino yazdı:
(01/11/2018, 16:04)Allback yazdı:
(01/11/2018, 12:07)notrino yazdı: Merhabalar,

Bildiğiniz üzere, bir VT bölündüğünde kullanıcı PC sindeki form ve sorgularla birlikte, yanında ok işareti olan tablo sembolü görünüyor. Kullanıcı bu tabloyu silse de sadece bağlantıyı silmiş oluyor, orjinal veritabanındaki tablo korunmuş oluyor. Ancak kullanıcı, bu ok işaretli tabloyu tıklayıp içine girdiğinde istediği kaydı silebiliyor. Yani tabloyu silmese bile istediği tüm kayıtları silebiliyor. O zaman veri güvenliği tehlikede değil mi?

Verileriniz tabii ki tehlikede ama bunu minimize etmenin yolları var.

Bunlardan en önemlileri verilerinizin belirli periyotlar ile yedeklerini almak ve otomatik aldırmak.
Diğer bir konu da kullanıcıların tablolara direk erişimini engellemek için, tüm işlemlerini form üzerinden yapacak şekilde tasarım yapmak. (pencereleri gizlemek ve bir tane ana form yapıp, bütün formlara erişimi bu ana form üzerinden yaptırmak gibi)

Evet, dedikleriniz doğru. Ama bölünmüş, sonra bir güzel mde yapılmış bir veritabanında, form-rapor gibi nesneler silinemez, tasarım formatında açılamaz, VB kodlara ulaşılamazken (yani form-rapor-kod güvenliği sağlanmışken) aynı güvenliğin "ok işaretli tablo" sembolü için sağlanamamış olması ne tuhaftır. Bu o kadar zor bir şey mi ki bunu yapamamış Access? Sırf tablo içindeki verileri korumak adına Access penceresi gizleme, Shift ile açmayı gizleme gibi, VT tasarlayan kişiye bir sürü takla attırmanın ne alemi var anlayamıyorum? Veritabanının orjinalini elinde tutan tasarımcı her türlü yetkiye sahip olsun tabi de masaüstünde sadece mde bulunan kullanıcılara ne diye tabloya erişim imkanı sunmuşlar bu anlaşılır değil..Bir veritabanı mde olduysa tablodaki ham verilere müdalehe de disable olmalı değil mi? Yanlış mıyım?

Bu sorunuzun muhattabı sanırım Microsoft E yani teknik olarak serzenişim Microsoft'a tabi de..Gıyabında bu işle uğraşan herkese. Benim gibi basit bir kullanıcı bile bu tehdidi görebiliyorsa Microsoft'un görememesi gibi bir şey söz konusu olabilir mi? Tuhaf değil mi?
02/11/2018, 07:43

alpeki99

Geçen gün mesajımda bahsettiğim gibi Microsoft bile bu ürüne en fazla bu kadar sahip çıkıyorken bunun eğitimleri için sertifika vs. vermek boşa çaba diye bu vb. daha pek çok şey için bahsetmiştim. Yalnız elbette bunun çok ama çok basit çözümleri var.

Öncelikle Access sadece bu tarz bir kullanım için hazırlanmadı. Yani siz bir web sitesi içinde veritabanı olarak Access kullanacaksanız -gerçi artık kullanan yok- bu durumda veriler için endişelenmenize gerek yok. Basit ama yeterince güvenli olmayan bir diğer yöntem veritabanına şifre koymak. Şifreyi bilmeyince tabloları görüntüleyip değiştiremezler. Tabi 1 sn içinde veritabanı şifresini veren programlar ile bu engel de rahatlıkla aşılabilmektedir.

Asıl çözüm ise Access'i sadece FE tarafında kullanıp BE tarafında ise MsSql ya da MariaDb gibi üstadları kullanmak olacaktır. Böylelikle kimse veritabanındaki verilere ulaşamaz dahi.
1 2 3