Cada vez más conscientes de la importancia de la seguridad informática, las empresas buscan soluciones más eficientes para evitar la fuga de información. La empresa de reciente creación, SeguridadCero, mayoristas de seguridad informática, ha traído al mercado español la aplicación AppDetective Pro. Este programa, una vez instalado en cualquier ordenador de una red local, realiza una búsqueda rápida de todas las bases de datos instaladas en cualquiera de los ordenadores. Una vez localizadas éstas, las examina remotamente en busca de fallos de seguridad; y cuando los detecta, arregla estos, proporcionando los parches de seguridad necesarios.
Este mismo programa también sirve a los auditores para localizar bases de datos en una red, con el fin de tenerlas controladas en los informes para la agencia de protección de datos. Las bases de datos que puede sonsacar AppDetective Pro son MySQL, Oracle, Sybase, IBM DB2, Lotus Notes, y Microsoft SQL Server. Aparte de controlar bases de datos web, por ejemplo, también inspecciona y vigila Microsoft Access. Con esta aplicación es imposible que se escape una sola base de datos en una red local, por muy oculta que esté, aparte de que se garantiza que no haya un solo fallo de seguridad.
Enlace: SeguridadCero
Mostrando las entradas con la etiqueta base de datos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta base de datos. Mostrar todas las entradas
Checklist para un Administrador de Base de Datos
Una mañana antes de ir al trabajo, te llaman para decirte que no pueden ingresar al sistema o que se cuelga repetidamente por que la base de datos parece demorar en responder. ¿Algo familiar? Si te encargas de manejar la red de una empresa, y en especial de administrar la base de datos corporativa, esto podría repetirse varias veces.
Algunas cosas no se pueden evitar o preveer, pero otras si, si tenemos una lista de acciones a comprobar y realizar durante nuestro trabajo. No todas las ocurrencias desapareceran, pero podremos minimizarlas, al asegurarnos que nuestro servidor (o servidores) y nuestra base de datos están trabajando corectamente.
Podemos dividir a ese proceso en dos: un checklist de acciones y aspectos a revisar y un registro de lo chequeado y como se solucionó, de modo que tengamos una base para resolver un problema similar en el futuro.
Digamos que para tener una idea de lo que vamos a chequear es encontrar las respuestas a estas preguntas:
Claro que si ya desempeñas el mismo trabajo por un lapso de tiempo regular, ya tenemos una lista "mental" de chequeo a nuestra base de datos y servidor. Pero seguramente la mayoría no lo tienen escrito en un documento, que podría servir a un asistente o en caso extremo a un reemplazo nuestro. Hay que pensar que no somos eternos ni nunca nos vamos a enfermar.
Sigue leyendo...
Empecemos a ver cual sería una lista básica de chequeo:
-Copias de Seguridad o Backups: Verificar que las copias de seguridad se realicen correctamente y que se completen. Anotar o indicar a quien se le comunica en caso esto falle. Revisar la causa de porque no se completo el backup o porque se convirtió en un backup corrupto. También es necesario verificar que el tiempo que demora en realizarse un backup es el necesario y no se extiende más allá de lo debido. Si el tiempo aumenta, investigar el porqué y documentar tal incidencia. Y lo más importante es verificar que todas las bases de datos a las cuales hay que realizar una copia de seguridad las tengan actualizadas. Podría ser importante tener una solución automatizada para las copias de seguridad, y en su defecto una hecha a mano, como la copia de seguridad que realizo con Winrar.
-Espacio en disco: hay que verificar el espacio libre de cada disco duro de los servidores. Si hay una reducción significativa del espacio en disco se debe averiguar la razón.
-Fallos en los trabajos programados. Chequear, si es que tenemos trabajos programados, la razón porque fallan.
-Chequeo del Sistema: revisar el registro de cada servidor y resolver en caso se detecte un error grave. A la vez chequear en el Visor de Sucesos (Windows) el registro de Aplicación.
-Desempeño: chequear estadisticas para los servidores y investigar para resolver cualquier caso. Que las estadisticas se encuentren dentro de lo normal.
-Conectividad: que los clientes se conecten a la base de datos y puedan consultar los datos correctamente y a una velocidad aceptable.
-Replicación: en caso se tenga bases de datos replicadas, verificar que el distribuidor replique correctamente a cada suscriptor. Y que cualquier cambio en el proceso una detención, un reinicio, sea notificado al administrador.
Esa sería una lista básica, que aseguraría un desempeño fiable de un servidor y una base de datos. Luego del chequeo viene el registro (escrito o en la computadora), marcando con fecha y nombre de quien resolvió el problema si hubiera ocurrido.
Algunas cosas no se pueden evitar o preveer, pero otras si, si tenemos una lista de acciones a comprobar y realizar durante nuestro trabajo. No todas las ocurrencias desapareceran, pero podremos minimizarlas, al asegurarnos que nuestro servidor (o servidores) y nuestra base de datos están trabajando corectamente.
Podemos dividir a ese proceso en dos: un checklist de acciones y aspectos a revisar y un registro de lo chequeado y como se solucionó, de modo que tengamos una base para resolver un problema similar en el futuro.
Digamos que para tener una idea de lo que vamos a chequear es encontrar las respuestas a estas preguntas:
- ¿Que debo chequear en la mañana?
- ¿Como realizo ese chequeo?
- ¿Que se debe hacer en caso encontrar un problema o fallo?
- ¿Hay alguien a quien avisar si hay una falla o problema?
Claro que si ya desempeñas el mismo trabajo por un lapso de tiempo regular, ya tenemos una lista "mental" de chequeo a nuestra base de datos y servidor. Pero seguramente la mayoría no lo tienen escrito en un documento, que podría servir a un asistente o en caso extremo a un reemplazo nuestro. Hay que pensar que no somos eternos ni nunca nos vamos a enfermar.
Sigue leyendo...
Empecemos a ver cual sería una lista básica de chequeo:
-Copias de Seguridad o Backups: Verificar que las copias de seguridad se realicen correctamente y que se completen. Anotar o indicar a quien se le comunica en caso esto falle. Revisar la causa de porque no se completo el backup o porque se convirtió en un backup corrupto. También es necesario verificar que el tiempo que demora en realizarse un backup es el necesario y no se extiende más allá de lo debido. Si el tiempo aumenta, investigar el porqué y documentar tal incidencia. Y lo más importante es verificar que todas las bases de datos a las cuales hay que realizar una copia de seguridad las tengan actualizadas. Podría ser importante tener una solución automatizada para las copias de seguridad, y en su defecto una hecha a mano, como la copia de seguridad que realizo con Winrar.
-Espacio en disco: hay que verificar el espacio libre de cada disco duro de los servidores. Si hay una reducción significativa del espacio en disco se debe averiguar la razón.
-Fallos en los trabajos programados. Chequear, si es que tenemos trabajos programados, la razón porque fallan.
-Chequeo del Sistema: revisar el registro de cada servidor y resolver en caso se detecte un error grave. A la vez chequear en el Visor de Sucesos (Windows) el registro de Aplicación.
-Desempeño: chequear estadisticas para los servidores y investigar para resolver cualquier caso. Que las estadisticas se encuentren dentro de lo normal.
-Conectividad: que los clientes se conecten a la base de datos y puedan consultar los datos correctamente y a una velocidad aceptable.
-Replicación: en caso se tenga bases de datos replicadas, verificar que el distribuidor replique correctamente a cada suscriptor. Y que cualquier cambio en el proceso una detención, un reinicio, sea notificado al administrador.
Esa sería una lista básica, que aseguraría un desempeño fiable de un servidor y una base de datos. Luego del chequeo viene el registro (escrito o en la computadora), marcando con fecha y nombre de quien resolvió el problema si hubiera ocurrido.
8 pasos simples para proteger las bases de datos
Estos son 8 pasos simples para proteger las bases de datos:
Sigue leyendo...
1.Monitorear directamente tus bases de datos financieras.
Evitar que usuarios acceden secretamente a los datos y asegurate de tener herramientas que alerten acerca de accesos no permitidos a las bases de datos financieras.
2.Remediar debilidades del control del acceso a las bases de datos
Passwords débiles o inexistentes constituyen una puerta abierta a usuarios no autorizados para que accedan a las bases de datos.
3.Auditar el acceso
Revisar y comprobar permisos adecuados de los usuarios. Debes asegurarte de tener la facilidad para conceder y revocar permisos.
4.Saber como utilizan los usuarios la base de datos
Y detectar a partir de los comportamientos normales, comportamientos anómalos que puedan comprometer la seguridad.
5.Verificar la autenticidad de las transacciones
6.Revisiones independientes
A pesar de los anteriores pasos, usuarios con experiencia o acceso alto, podrían estar alterando datos en la base de datos. Hay que identificar movimientos sospechosos con un software de auditoría especial, ya que el mismo software que accede a la base de datos no podría estar mostrando los verdaderos datos.
7.Automatizar controles para disminuir costos de auditoría anuales
Auditorías anuales son tediosas y complicadas. Y aumentan los costos de las empresas. Al automatizar controles, acelera la detección de problemas y su posterior resolución.
8.Emplear encriptación para proteger los datos
A pesar que hay passwords y niveles de acceso, debería considerarse la encriptación de datos como una regla.
Fuente:
http://www.eweek.com/c/a/Enterprise-Apps/8-Simple-Steps-to-Protect-Your-Database/
Sigue leyendo...
1.Monitorear directamente tus bases de datos financieras.
Evitar que usuarios acceden secretamente a los datos y asegurate de tener herramientas que alerten acerca de accesos no permitidos a las bases de datos financieras.
2.Remediar debilidades del control del acceso a las bases de datos
Passwords débiles o inexistentes constituyen una puerta abierta a usuarios no autorizados para que accedan a las bases de datos.
3.Auditar el acceso
Revisar y comprobar permisos adecuados de los usuarios. Debes asegurarte de tener la facilidad para conceder y revocar permisos.
4.Saber como utilizan los usuarios la base de datos
Y detectar a partir de los comportamientos normales, comportamientos anómalos que puedan comprometer la seguridad.
5.Verificar la autenticidad de las transacciones
6.Revisiones independientes
A pesar de los anteriores pasos, usuarios con experiencia o acceso alto, podrían estar alterando datos en la base de datos. Hay que identificar movimientos sospechosos con un software de auditoría especial, ya que el mismo software que accede a la base de datos no podría estar mostrando los verdaderos datos.
7.Automatizar controles para disminuir costos de auditoría anuales
Auditorías anuales son tediosas y complicadas. Y aumentan los costos de las empresas. Al automatizar controles, acelera la detección de problemas y su posterior resolución.
8.Emplear encriptación para proteger los datos
A pesar que hay passwords y niveles de acceso, debería considerarse la encriptación de datos como una regla.
Fuente:
http://www.eweek.com/c/a/Enterprise-Apps/8-Simple-Steps-to-Protect-Your-Database/
Lista de Profesiones
En esto también ayuda el INEI, se descarga la lista de profesiones desde aquí. El problema es que hay abundancia de información que no va a ser necesaria.
Solo hay que filtrar las profesiones, no los grupos (gran grupo, grupo y subgrupo), es decir solo lo que en la tabla se define como Apertura.
Nuevamente hay que filtrar solo esos datos y importarlos a la base de datos.
Solo hay que filtrar las profesiones, no los grupos (gran grupo, grupo y subgrupo), es decir solo lo que en la tabla se define como Apertura.
Nuevamente hay que filtrar solo esos datos y importarlos a la base de datos.
Lista de Departamentos, Provincias y Distritos del Peru
En la página del INEI, se puede descargar el UBIGEO2006, una tabla en DBF, que contiene la lista de los departamentos, provincias y distritos del Perú. Esta actualizada a mayo del 2006, y como es dificil que hayan aparecido nuevos distritos, lo vamos a usar.
Primero lo descargamos de aquí, consiste en un archivo ZIP con un PDF y un DBf en su interior. En el DBF están los datos que necesitamos, es decir los departamentos, provincias y distritos. Eso es bueno, excepto por el hecho que están en una sola lista. La forma de extrae los datos adecuados están en el pdf.
Si son departamentos, los campos CodProv y CodDist son iguales a '00'.
Si son provincias, el campo CodDist es igual a '00' y el campo CodProv es diferente de '00'.
Si son distritos todos los campos son diferentes de '00'.
Necesitamos importarlo a nuestras tablas Departamento, Provincia y Distrito. El tema es separar la paja del arroz, digo los departamentos de las provincias y de los distritos.
Con las sentencias anteriores se llenan las tablas, he combinado los campos debido a que los codigo de la tabla Ubigeo se repiten en provincias y distritos, asi me aseguro que sean unicos.
Primero lo descargamos de aquí, consiste en un archivo ZIP con un PDF y un DBf en su interior. En el DBF están los datos que necesitamos, es decir los departamentos, provincias y distritos. Eso es bueno, excepto por el hecho que están en una sola lista. La forma de extrae los datos adecuados están en el pdf.
Si son departamentos, los campos CodProv y CodDist son iguales a '00'.
Si son provincias, el campo CodDist es igual a '00' y el campo CodProv es diferente de '00'.
Si son distritos todos los campos son diferentes de '00'.
Necesitamos importarlo a nuestras tablas Departamento, Provincia y Distrito. El tema es separar la paja del arroz, digo los departamentos de las provincias y de los distritos.
select * from ubigeo2006
/*departamentos*/
insert into departamento(IdDepartamento,Nombre,idpais)
select coddpto,nombre,'173' from ubigeo2006 where codprov='00' and coddist='00'
/*provincias*/
insert into provincia(Idprovincia,Nombre,iddepartamento)
select codprov+coddpto,nombre,coddpto from ubigeo2006 where coddist='00' and codprov<>'00'
/*distritos*/
insert into distrito(Iddistrito,Nombre,idprovincia)
select coddist+codprov+coddpto,nombre,codprov+coddpto from ubigeo2006 where coddist<>'00' and codprov<>'00' and coddpto<>'00'
Con las sentencias anteriores se llenan las tablas, he combinado los campos debido a que los codigo de la tabla Ubigeo se repiten en provincias y distritos, asi me aseguro que sean unicos.
Lista de Paises
Para obtener una lista de paises, descargue un archivo de texto de la página de la ISO, hay una lista en inglés y la otra en francés. Es suficiente con la lista en inglés, además este es un sistema de planillas simple, y no creo que la empresa vaya a contratar a un macedonio o un koreano, pero hay que tener aspiraciones grandes, de repente a una multinacional le gusta el programita.
La lista de paises se puede descargar desde aqui.
Descargué la lista, y la importe a la base de datos. Con los parámetros que se pueden ver en las imagenes (haz clic para que se vea más grande).
Luego añadí un campo autonumerico a la tabla creada (Paises por ejemplo) para que sea la clave primaria. Si se dan cuenta en la lista se muestra el nombre del país y la abreviatura del nombre.
Y listo, ahora necesitamos la lista de departamentos, provincias y distritos de Perú. El resto de países según sea necesario, los irá agregando el usuario.
La lista de paises se puede descargar desde aqui.
Descargué la lista, y la importe a la base de datos. Con los parámetros que se pueden ver en las imagenes (haz clic para que se vea más grande).
Luego añadí un campo autonumerico a la tabla creada (Paises por ejemplo) para que sea la clave primaria. Si se dan cuenta en la lista se muestra el nombre del país y la abreviatura del nombre.Y listo, ahora necesitamos la lista de departamentos, provincias y distritos de Perú. El resto de países según sea necesario, los irá agregando el usuario.
El nombre y mas
Se me ocurrio ponerle Axim Planillas, Axim por el nombre de mi hija Ana Ximena, y Planillas pues es obvio. No es de grandes pretenciones, solo un sistema de escritorio pequeño de 1 a 5 usuarios.
La base de datos se llamará AximPlanBD en Sql Server 2000, la interfaz será en Visual Basic 2005.
La base de datos se llamará AximPlanBD en Sql Server 2000, la interfaz será en Visual Basic 2005.
Descarga Oracle 10g
Suscribirse a:
Entradas (Atom)
