SELinuxの導入には検証が必要

Fedoraでは,Fedora core 2からSELinuxが導入されています。FedoraサーバーはSELinuxの設定が難しいため,長年当方の業務サーバーでもOFF(disable)にしていました。システムのセキュリティを高めるSELinuxは,強力な機能を持つ一方で,初めて導入する際には設定や運用が複雑で戸惑うこともあります。ここでは,SELinuxの初期設定から運用までのポイントを具体例とともに解説します。


  1. 初期設定:SELinuxを「Permissiveモード」で開始する

SELinuxを導入する際には,まず「Permissiveモード」で動作させ,エラーや警告を監視できる状態に設定するのが良い方法です。

  • カーネルパラメータの設定変更
    SELinuxを完全に無効化(disable)するのではなく,監査モードでエラーを検出できるようにします。
grubby --update-kernel ALL --remove-args selinux

vi /etc/selinux/config

SELINUX=permissive

上記の設定変更後,システムをリブートします。

  1. エラー確認コマンド
    SELinux関連のエラーは以下のコマンドで確認できます。
#直近10分前のエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

#今日発生したエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today

#昨日と今日のエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts yesterday

各アプリケーションごとの設定例

SELinuxでは,アプリケーションごとに必要な権限を付与する必要があります。以下に具体例を示します。


  1. Samba(ファイルサーバー)

Windowsからファイル共有する場合,以下の設定を行います。

setsebool -P samba_export_all_ro=1 samba_export_all_rw=1
  1. OpenVPN(VPNサーバー)

使用するポートを指定してSELinuxに許可を与えます。

semanage port -a -t openvpn_port_t -p tcp 利用ポート
  1. Apache(Webサーバー)

Apacheでファイル出力やCGI実行を行う場合の設定例です。

  • ファイル出力用ディレクトリ
chcon -R -t httpd_sys_rw_content_t /var/www/cgi-bin/tmp
  • CGIファイルの実行権限
chcon -t -R httpd_sys_script_exec_t /var/www/cgi-bin/tmp/*.cgi
  • (例)特に昔のPukiWikiについては,以下の設定でうまくいました。
chcon -R -t httpd_sys_rw_content_t /var/www/cgi-bin/Pukiwiki
chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/Pukiwiki/
chcon -R -t httpd_sys_script_exec_t /var/www/cgi-bin/Pukiwiki/plugin
  1. WordPress(CMS)

WordPressは複数の設定が必要です。以下に代表的な例を示します。

  • ネットワーク接続の許可
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect=on
  • ディレクトリごとの権限設定
#wordpressディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_content_t "/var/www/cgi-bin/wordpress(/.)?"
semanage fcontext -a -t httpd_sys_script_exec_t "/var/www/cgi-bin/wordpress/..php"
restorecon -R -v /var/www/cgi-bin/wordpress

#wordpressのcontentディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/wordpress/wp-content(/.*)?"
restorecon -R -v /var/www/cgi-bin/wp-content

#wordpressのincludesディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_script_exec_t "var/www/cgi-bin/wordpress/wp-includes/.*.php"
restorecon -R -v /var/www/cgi-bin/wordpress/wp-includes/
  • プラグインやメール配信(例:MW WP Formプラグイン)
setsebool -P httpd_can_sendmail 1

任意のアプリーケーション

アプリケーションの動作でエラーが発生する場合,SELinuxログを基にカスタムルールを作成します。以下はルール作成の手順です。

  1. エラーログを確認とポリシーの作成
ausearch -m AVC --start '11/29/24' --end now

(出力例)
time->Tue Dec 3 xx:xx:xx 2024
type=PROCTITLE msg=audit(xxxxxxxxxxxx.xxx:xxxxx): proctitle=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
type=SYSCALL msg=audit((xxxxxxxxxxxx.xxx:xxxxx): arch=x00000xx syscall=xxx success=no exit=-13 a0=ffffffxx a1=xxxxxxxxxxxxxxxxx a2=0 a3=0 items=0 ppid=xxxxx pid=xxxxx auid=xxxxxxxxxxx uid=xx gid=xx euid=xx suid=xx fsuid=xx egid=xx sgid=xx fsgid=xx tty=(none) ses=xxxxxxxxxxx comm=”xxxx” exe=”/usr/sbin/xxxxxxxxx” subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(xxxxxxxxxxxxxxx.xxx:xxxxx): avc: denied { read } for pid=xxxxx comm=”xxxx” name=”xxxx.xxxx” dev=”dm-0″ ino=xxxxxxxxx scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=file permissive=0

tmp_ruleがルール名としてアプリケーション実行日と開始時間を下記に入れて,実行後,素早く実行します。

#下記の例 '月/日/年(2桁)' '時:分:秒' 
ausearch -m AVC --start '11/29/24' '20:39:40' --end now | audit2allow -a -M tmp_rule

これにより,tmp_rule.pp(ポリシーファイル)が生成されます。

  1. ポリシーの適用
semodule -i tmp_rule.pp
  1. ルールを適用してauditaのエラーが出なくなるかを確認します。
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

この方法により,faxやefaxというFAXサーバーについても問題なく運用できるようになりました。


・SELinuxの有効化

1日2日「SELINUX=permissive」のまま

ausearch -m AVC,USER_AVC,SELINUX_ERR -ts yesterday

を入力してログを確認して以下のようにエラーが出なくなることを確認します。

<no matches>

これにより,SELinuxを起動させます。

setenforce 1
vi /etc/selinux/config

SELINUX=enforcing

これによって晴れてSELinuxが運用できるようになりました。


運用上の注意点

  • SELinuxは強力なセキュリティを提供しますが,設定ミスやエラーが原因でアプリケーションが動作しないことがあります。そのため,導入時は「Permissiveモード」で充分に検証してください。
  • 運用中に発生する問題は,適宜ログを確認し,必要に応じてカスタムルールを作成します。

SELinuxの導入と運用には一定の時間と手間がかかりますが,正しく設定すれば堅牢なセキュリティを実現できます。ぜひ,計画的に導入を進めてみてください。

自爆営業がパワハラの指針に

パワハラ(パワーハラスメント)は,多くの人がその定義や適用範囲に疑問を抱くことが少なくありません。これは,言葉として広く知られる一方で,具体的な行為や状況の認識が難しいためです。今回は,その定義と最近の話題である「自爆営業」への対応について解説します。


パワハラの定義

厚生労働省は,パワハラに関する指針を令和2年に発表しています(令和2年厚生労働省告示第5号)。この指針では,パワハラを以下の3つの要素で構成されるものと定義しています。

  1. 優越的な関係を背景とした言動
    上司から部下,または特定の役割や立場を利用して行われる行為を指します。例えば,地位や権限を利用しての圧力や命令などが該当します。
  2. 業務上必要かつ相当な範囲を超えたもの
    業務の指示や指導であっても,その範囲を逸脱した不適切な行為はパワハラとされます。過度な叱責や不要な業務負担がこれに該当します。
  3. 労働者の就業環境が害されるもの
    心理的・身体的負担を引き起こし,労働者が仕事を続けられない状態に追い込まれる場合です。

これらの3つの要素すべてが満たされた場合に、パワハラとして認定されます。


「自爆営業」とパワハラ

最近,厚生労働省は指針に「自爆営業」をパワハラの具体例として明記する方針を示しました。(参考 毎日新聞社【厚労省、「自爆営業はパワハラ」指針に明記へ 賃金格差公表拡大も】)
「自爆営業」とは,企業が従業員に対して商品やサービスを購入させる行為を指します。この問題は以前から労働環境に悪影響を与える行為として指摘されており,パワハラに該当すると考えられます。

自爆営業はパワハラの要件を満たすケースが多いため,指針に明記されることになりました。


今後への期待

「自爆営業」がパワハラの具体例として記載されることにより,職場での不適切な行為を減らす効果が期待されます。これにより,従業員が安心して働ける環境が整備されることを望みます。

Fedoraサーバーでの頻発するリブートとjournalのエラーへの対処方法

最近,Fedora38からFedora41へとアップデートを行ったサーバーで,3~5時間に1回程度,勝手にリブートがかかるという問題が発生しました。この問題の原因を調査し,最終的に解決した方法について記録します。

問題の概要

はじめに,リブートのタイミングがcrontabで実行されるジョブの時間と一致していたため,定期実行されるプログラムが原因と考えました。しかし,問題を掘り下げるうちに,以下の状況が判明しました。

  1. SELinuxをPermissiveモードに設定すると,さらにリブート頻発時間が短くなる
  2. リブート直前のログが不完全で,途中で切れている/var/log/messages
  3. journalctl --verifyコマンドでジャーナルログの破損を検出

エラーログの確認

リブート直前のログは以下のように記録されていました:

Nov 14 06:40:11 server audit[1]: SERVICE_STOP pid=1 uid=0 auid=xxxx ses=xxxx msg='unit=user-runtime-dir@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 06:40:11 server systemd[1]: Removed slice user-0.slice - User Slice of UID 0.
Nov 14 06:40:11 server systemd-logind[748]: Removed session 548.
Nov 5 15:13:30 server su[1540]: (to root) user on pts/0
Nov 5 15:19:00 server smbd[2128]: [2024/11/05 15:19:00.003114, 0] ../../source3/smbd/msdfs.c:97(parse_dfs_path_strict)

journalctl --verifyを実行すると,次のエラーが確認されました:

71ce810: Data object references invalid entry at 10598418
File corruption detected at /var/log/journal/xxxx/system.journal:274295040 (of 276824064 bytes, 99%).
FAIL: /var/log/journal/xxxx/system.journal (不正なメッセージです)
PASS: /var/log/journal/xxxx/user-1000.journal

どうやら,ジャーナルログが破損しており,これが原因でjournaldrsyslogの動作に影響を与えている可能性が高いことがわかりました。


試行錯誤と対策

ログの破損を防ぐため,以下の対応を試みました。

  1. 過去のジャーナルログを削除
journalctl --rotate
journalctl --vacuum-time=1s
  1. ジャーナルログのサイズ制限
    /etc/systemd/journald.confを編集して以下の設定を追加:
SystemMaxUse=2G
SystemMaxFileSize=500M

設定変更後にサービスを再起動:

systemctl restart systemd-journald
  1. ハードウェア検査
    メモリーテスト(Memtest)やSSDのSMART情報をチェック(smartctl -x /dev/sda など)しましたが,特に異常はありませんでした。
  2. Fedoraの再インストール
    上記の対応を行っても,症状が改善されることはありませんでした。そのため,Fedoraを再インストールしました。再インストール後も同様の症状があり,解決しませんでした。

最終的な解決策:サーバー本体(メインボード)の交換

上記の対応を行っても,症状が改善されることはありませんでした。そのため、最終的にメインボードの交換をしました。サーバーの交換後,以下を確認しました:

  • journalctl --verifyでログ破損なし
  • リブートが発生しない

これにより,ハードウェア自体に何らかの故障があった可能性が高いと結論付けました。


再発防止のための設定

再インストール後は,以下のポイントを守ることで,再発を防ぐ体制を整えました。

  1. ジャーナルログの定期チェック
journalctl --verify
  1. バックアップの確保
    システムの変更前に設定ファイルや重要なデータをバックアップ
  2. ハードウェア診断の定期実施
    定期的にメモリやディスクの健全性を確認

まとめ

今回の問題では,サーバー本体の交換が最終的な解決策となりました。おそらく,SSDやメモリー以外のメインボード等のハードウェアが故障した可能性が高いと推測されます。同様の問題に遭遇した際には,まずジャーナルログの破損を疑い,ハードウェアの状態を慎重に確認することも視野に入れる必要がありそうです。

直系尊属が一部重なる養子縁組でも親が異なる場合は代襲相続権はない

令和6年11月12日に最高裁判所第三小法廷で下された判決により,被相続人の親の養子縁組による兄弟姉妹の子(養子縁組前に出生)が代襲相続権を持たないという判断が示されました。この判決は,相続法の適用範囲における重要な判例として注目されています。

(図 被相続人の義理の兄弟姉妹の子の代襲相続権はなし)

判決の概要

  1. 争点
    被相続人の義理の兄弟姉妹の子が代襲相続人となるかが争点となりました。具体的には,養子縁組が成立する前に生まれた子(養子縁組前の子)が,被相続人の兄弟姉妹の代襲相続人となる資格を有するかが問われました。
  2. 最高裁の判断
    養子縁組前に生まれた子については,たとえ被相続人の兄弟姉妹と祖父母が同じ傍系尊属であっても,代襲相続権は認められないと結論付けられました。
    • 法的背景: 民法上,代襲相続は「被相続人の直系卑属」または「被相続人の兄弟姉妹の直系卑属」に認められるものであり(民法第887条,第889条第3項),養子縁組により新たに形成された法的親族関係は,縁組後に限り効力を持つと解釈されました。
      【民法第727条,大審院昭和6年(オ)第2939号,昭和7年5月11日判決】

意義と影響

今回の判決は,代襲相続人の範囲を明確化し,相続法の適用範囲における制限を示す重要な判断です。養子縁組の効力が縁組後に生じるという原則が再確認され,代襲相続の範囲が明確に限定されました。

結論

代襲相続人が広がるかもしれない判断がされるかと思われましたが,今回は養子縁組前に生まれた子の代襲相続権は,祖父母が同じ傍系尊属であっても明確に認められないことになります。
(参考 日本経済新聞社【養子縁組後の遺産、親に代わり相続「できず」 最高裁】)

SELinuxのPermissiveの検証でサーバーにリブートし続ける症状が発生

FedoraサーバーでSELinuxを有効にした際の検証プロセスについて,以下の手順と注意点をまとめました。

SELinuxの有効化とモードの設定

内部サーバーのセキュリティ強化のため,SELinuxを有効にしてPermissiveモードでの検証を行いましたが,今回発生した不具合と対処方法を示します。

SELinuxの有効化手順

1.grubbyコマンドを使用してSELinuxを有効化
SELinuxを有効化したい場合,以下のコマンドを使用します。

grubby --update-kernel ALL --remove-args selinux

2.SELinuxのPermissiveモードへの切り替え
SELinuxを有効にしてもいきなりファイルアクセスが制限されないよう,Permissiveモードで動作検証します。これはSELinuxの設定ファイルを編集することで行います。

vi /etc/selinux/config
SELINUX=enforcing

SELINUX=permissive

予期せぬリブートの問題

SELinuxの初回有効化時,ファイルの再ラベリングが自動的に行われるため,その影響でシステムがリブートを繰り返す現象が発生しました。ログによると,/dev 以下でのエラーや,一部の手動で作成したサービスがリブート時に問題を引き起こしていたようです。

対処方法:手動での再ラベリング

1.レスキューモードでの起動
ブートローダーのメニュー画面でレスキューモードの位置で「e」キーを押し,編集画面から「F10」でブートを開始します。

2.手動ラベリングの実行
root権限でログインし,次のコマンドを使って手動で再ラベリングを行います。

/sbin/fixfiles -f -F relabel
reboot

3.再起動後の確認
正常に起動できることを確認し,Permissiveモードでの検証を続けます。

結果と考察

手動の再ラベリングによって,Permissiveモードでのシステムの安定起動が確認できました。なお、手動で作成したサービスや/dev以下のファイルに起因するSELinux関連のエラーが発生する場合には,上記の再ラベリングの作業をする必要があると考えられます。

SELinuxの設定はかなり難しいと感じていますが,今後いつか設定方法をご報告できたらと思います。



Linux(Fedora)サーバーでVPN利用時のVoipとNAT変換の動作

Fedoraサーバーへのセキュリティ向上のため、ファイアウォール設定を従来のiptablesからFirewalldへ移行しましたが、移行後に内線電話で利用しているSIPサーバーが正常に動作しない事態が発生しました。このようなケースにおける検証結果と解決策についてご紹介します。

SIPサーバーは以下のとおりで使っています。

業務ネットワークイメージ

問題の発生状況

Fedoraサーバー上では,SIPサーバーを通じて業務ネットワーク内のWiFi接続(192.168.0.xおよび192.168.1.x)でSIPクライアントを利用しています。SIPクライアント(iphoneアプリ)として使用しているのはAGEPhoneで,VPN経由で接続しています。

移行後,SIPクライアントが「403 Forbidden」エラーを返し,通信ができなくなっていることが判明しました。
パケットキャプチャを使用して詳細を調べたところ,IPマスカレード(NAT変換)の動作により,SIPプロトコルが正しく機能しなくなっていたことがわかりました。

検証結果と原因

以下のように,Firewalldによる設定ではVPNのホスト名に変換され,SIPサーバーが要求するIPアドレス認証に一致しないため,403エラーが発生していました。

すると,iptablesでは,ipアドレスでSIPサーバーにアクセスしていましたが,Firewalldでは,NAT変換されてしました。(「tcpdump host 192.168.0.3」で検証)

iptablesの設定:

192.168.1.x > 192.168.0.3 (SIPのIPアドレスで通信)

Firewalldの設定(IPマスカレード設定時):

vpn.example.com > 192.168.0.3 (ホスト名に変換され通信不可)

この問題の原因は,SIPが発信元IPアドレスの一貫性を必要とする仕様により,NAT変換されたアドレスを受け入れないことにありました。

解決策

Firewalldの設定を見直し,IPマスカレード(NAT変換)を解除することで,SIPサーバーが元のIPアドレスで通信できるようにしました。具体的には,以下のコマンドを使用しました。

firewall-cmd --zone=internal --remove-masquerade --permanent
firewall-cmd --reload

この設定変更により,異なるローカルネットワークでも直接IPアドレスがやり取りされ、SIP通信が可能になりました。パケットキャプチャ上でも発信元のIPアドレスが確認できるようになりますが、SIPの仕様に従うための対応です。

SIPとNAT変換のドキュメントがなかなかありませんでしたが,学会論文誌に掲載がありました。
【情報処理学会論文誌:「ファイアウォールや NAT を通過できる IP 電話の提案と評価」 伊藤将志氏, 鹿間敏弘氏,渡邊晃氏】

他のサービスでの影響

SIPサーバー以外のサービス(Samba,Web,RDP,Ping,SSH等)は,IPマスカレードを使っていても問題なく動作しているため,通常はマスカレードを導入したほうが利便性が向上します。しかし,SIPサーバーを使用する場合は,IPマスカレード解除の設定を行うことが推奨されます。

まとめ

SIPサーバーの設定には,ファイアウォールの詳細設定が関わってきます。Firewalldに移行した際には,各サービスごとの通信要件を確認し,必要に応じてマスカレードの有無を調整することが重要なようです。今後も,安全かつ効率的なネットワーク運用を目指して設定の改善に取り組んでまいります。

Fedora40→41にアップグレード

当社では,安定性とセキュリティの向上を目的として,メインサーバーにLinuxディストリビューションのFedoraを採用しております。この度,Fedoraの最新バージョンへのアップデートを無事完了しましたので,報告いたします。

アップデートの手順

Fedoraのアップデートは,以下の手順に従って実施しました。これにより,システムの最新機能とセキュリティパッチを適用し,サーバーのパフォーマンスを最適化しています。
(参考 ninjav8氏アメーバブログ「Fedora Linux 40からFedora Linux 41にアップグレード」)

1.パッケージリストの更新とシステムのアップグレード

dnf --refresh upgrade

このコマンドにより,最新のパッケージ情報を取得し,既存のパッケージを最新バージョンに更新します。

2.システムアップグレードの準備

dnf system-upgrade download --releasever=41

Fedoraの次期リリースバージョン(ここではバージョン41)へのアップグレードをダウンロードします。

3.システムの再起動とアップグレードの適用

dnf system-upgrade reboot

サーバーを再起動し,ダウンロードしたアップグレードパッケージを適用します。

アップデート後の確認

アップデートが完了した後,以下のコマンドでシステムのバージョンを確認し,正常にアップグレードされたことを確認しました。

uname -a

アップデート時の注意点

Fedora 39から40へのアップデートと比較すると,特に注意点はありませんが,のアップデートでは以下の点に注意が必要です。

  • 手動での修正
    自動アップデートでは対応できない設定ファイルの調整が必要となる場合があります。特にカスタマイズされたアプリケーション(efaxやNextcloud等)の設定については,アップデート後に手動で修正を行うことがあります。
  • 互換性の確認
    特定のサービス(phpやperl等)やアプリケーションが新しいバージョンと互換性を持つかどうかをできるだけ事前に確認したほうがいいです。問題が発生した場合には,迅速に対応できるよう準備を整えていく必要があります。

今後の展望

今回のアップデートにより,サーバーの安定性とセキュリティが向上し,業務の効率化が期待されます。今後も定期的なシステムアップデートを実施し,最新の技術を取り入れることで,より安全で信頼性の高いサービスを提供してまいります。

また,アップデートに伴う設定変更やトラブルシューティングに関する情報を随時共有し,Linux等のサーバー構築に関するドキュメント公開の活発化に資することを目指します。

Linux(Fedora)サーバーでVPN利用時のfirewalld設定

最近,LinuxでVPNを利用する際のfirewalld設定に関する情報が少ないことから,独自に検証を行い設定方法をまとめました。特に,異なるネットワーク間で双方向に接続する構成のドキュメントが見当たらなかったため,以下に紹介します。

ネットワーク構成

以下の構成図で,LinuxサーバーをVPNゲートウェイとして複数ネットワークを接続します。

client(0.x)--rt(192.168.0.1)==grobal==rt(192.168.1.1)--client(1.x)
server(0.2)↑eth0 ↑server(1.2)
↑----------------------VPN-------------------------↑
192.168.2.1(eth1) 192.168.2.2

この構成で「双方向」に通信する場合には,VPN(OpenVPNなど)によって共通のネットワークエリアを形成し、server(0.2)側でfirewalldのゾーン設定を行う必要があります。

firewalld設定

VPN接続で別ネットワークを双方向に接続するため,server(0.2)側の設定では192.168.0.xのネットワークと192.168.2.xのネットワークを同じゾーンに設定します。例えば、ゾーンをinternalに設定する場合は以下の手順を行います。

1.デフォルトゾーンをinternalに設定

firewall-cmd –set-default-zone=internal

2.マスカレードと転送を有効化

firewall-cmd –zone=internal –add-masquerade –permanent
firewall-cmd –zone=internal –add-forward –permanent

3.インターフェースをinternalゾーンに追加

firewall-cmd –permanent –zone=internal –add-interface=eth1

4.設定のリロード

firewall-cmd –reload

同じゾーンにしないと片方からの通信のみ可能となってしまうことから,ゾーンは必ず同一にする必要があるようです。

ダイレクトルールの注意点

検証の結果,ダイレクトルール(firewall-cmd --permanent --direct)を用いると,予期しない挙動が生じ、通信が途絶えることがありました。確実な通信を目指す場合、ダイレクトルールの使用は避け,ゾーン設定を活用する方法をおすすめします。

この方法が皆様の環境構築の一助になれば幸いです。今後もこのような検証結果をもとに,最適な設定方法を紹介してまいります。

法律系士業の役割と業務範囲について

法律系の士業(弁護士や税理士など)は,その資格ごとに法律で定められた業務範囲があり,取り扱える業務とそうでない業務が明確に区分されています。当事務所では,取り扱えない業務が発生した際にはその旨をお伝えし,他の士業をご紹介するか,他士業に引き継ぐ形で対応いたします。以下に代表的な法律系士業の役割と業務範囲をご紹介いたしますので,参考にしていただければ幸いです。

各士業の主な役割と業務内容

  • 弁護士:訴訟事件や一般的な法律業務を担当します。(弁護士法第3条第1項)
  • 公認会計士:財務書類の監査と証明が主な業務です。(公認会計士法第2条第1項)
  • 税理士:税務代理や税務書類の作成・相談,財務書類の作成を行います。(税理士法第2条第1項・第2項)
  • 司法書士:不動産や会社・法人の登記手続き代理,訴状作成,供託申請の代理を担当します。(司法書士法第3条第1項)
  • 土地家屋調査士:不動産の表示登記,土地建物の調査測量を行います。(土地家屋調査士法第3条第1項)
  • 弁理士:特許,実用新案,意匠,商標の申請代理や鑑定業務が専門です。(弁理士法第4条第1項)
  • 社会保険労務士:雇用保険や労災保険,健康保険,年金関連の申請・届出書の作成代理を行います。(社会保険労務士法第2条第1項)
  • 行政書士:官公署へ提出する書類の作成・代理,権利義務や事実証明に関する書類の作成が業務範囲です。(行政書士法第1条の2第1項)
  • 海事代理士:船舶法や船員法,海上運送法等に定める申請・登記・届出の代理,書類作成を行います。(海事代理士法第1条)

各士業の業務範囲を理解することで,適切な専門家に相談しやすくなり,スムーズな対応が期待できます。今後のご相談の際にぜひご参考ください。

新しいサーバースペックとデータ保護の取り組み

当所では,効率的なデータ管理と高い信頼性を提供するため,メインサーバーのスペックを最新化しました。過去のクライアントPCをベースにしたこのサーバーは,SambaとNextcloudを中心としたファイルサーバー兼クラウドファイルサーバーとして稼働しています。

サーバースペック

  • OS:Fedora 40
  • CPU:Core i5-9400 (2.9GHz)
  • メモリ:40GB(16GB×2 + 4GB×2)
  • ストレージ:M.2 SSD 2TB

このスペックにより,安定したパフォーマンスとデータ処理の迅速化を実現しています。

データセキュリティと分離設計

登記データなどの重要情報は,公開されているWordPressサーバーとは物理的かつ回線的に分離したメインサーバーに保存されています。これにより,公開サーバーからのアクセスリスクを排除し,セキュリティを徹底しています。

データの多重化と完全削除の方針

ストレージの二重化は行っていませんが,データ保存の多重化を採用し,物理的な破損や誤削除が発生しても,重要な情報が簡単には失われない体制を整えています。
また,削除するデータは完全削除を行い,個人情報保護方針に基づいた運用を徹底しています。

今後もこのような取り組みを通じ,信頼性の高いサービスを提供し続けてまいります。