여기 게시판을 보다보니 몰랐던 사실을 알게되었는데 좀 충격적이더군요!
그건 바로 SYSDBA계정을 삭제하고 새로운 계정으로 디비파일을 생성한것이라도 파일만 복사해서 다른 피씨에 파이어버드를 설치하고 SYSDBA/masterkey로 열 수 있다는 문제입니다.
여기 게시판에 SYSDBA계정을 삭제하면 해결된다는 답변 글을 봤는데 파이어버드를 폴더까지 삭제후 새로 설치하면 바로 열린다는 겁니다. 즉,  security.fdb만 새로 넣어도 ....

이런 경우 리모트 디비로 생성한 경우 원격지에서 SYSDBA 계정으로 액세스 할 수 있다는 문제가 있는데
이럴땐 어떻해야 할 지 난감합니다. 3-Tier는 사정상 고려대상이 아닙니다.

http://www.firebirdsql.org/manual/fbmetasecur-solution.html

여기에선 해결방법을 보는데도 도무지 이해가 안갑니다. 영어가 짧아서...
데이터 자체를 암호화하는건 고려대상이 아니고 우선 SYSDBA 계정을 삭제 하는건데 관련지식이 모자라서 아래 글이 이해가 되질 않습니다.
저는 IBExpert에서 SYSDBA 계정을 삭제하고 새 유저를 추가한것이 전부라 무었을 더 해야 할지 가르침을 주십시오.
아래 글에서 Removing SYSDBA access와 제가  IBExpert에서 SYSDBA 계정을 삭제한 것의 차이점을 좀 알려주시면 감사하겠습니다. 뭔가 빠진게 있는것 같기도 하고....
대충보니 SYSDBA 계정을 삭제하면 다른 곳에 복사해도 SYSDBA로 액세스 할 수 없다는 내용같은데 실제로 해보면 그냥 열립니다. 그래서 이해가 안됩니다. 사용자는 security.fdb에 저장되어서 디비파일과는 무관할 것 같은데????

Removing SYSDBA access
At various times people have suggested that removing SYSDBA access to a database could be the solution. The idea behind it is that, when the database is moved to a new server where the SYSDBA password is known, it will not help the person because SYSDBA does not have access anyway. Some have reported limited success in this respect by creating an SQL role name of SYSDBA and making sure it does not have access to the database objects.

However it does not really solve the problem. The database file can be viewed with a hex viewer or similar utility and the list of available user names discovered. (Discovering the owners of the database objects would be particularly useful.) Once known, these names can be added to the new server and used directly.

An even simpler workaround might be to use the embedded version of Firebird server (see below) or to compile your own version of the Firebird server that ignores security constraints.