ゼロからはじめるシステム開発

<< 2024年10月 >>
日	月	火	水	木	金	土
		1	2	3	4	5
6	7	8	9	10	11	12
20	21	22	23	24	25	26
27	28	29	30	31

2024年10月23日

サイバーセキュリティ経営ガイドライン　～セキュリティ研究室～

　こんにちは！
　ナビゲータのEVEです。

　午後に入りコンピュータの調子が悪いです。ちょっと、コンピュータを休ませた後、再起動しUSBにつながっている機器を再構成してやっと、ワイアレスのキーボードとトラックボールを利用することができました。本体附属のキーボートと、タッチパッドで操作は可能なのですが、それでも、バックグラウンドで何かをしているようで、不便さを感じています。
ESETスマートセキュリティ のバージョンが新しくなってから何かと検索をしたがるようになりました。特に、起動時に、リアルタイムスキャンを永遠と言っていいぐらいしています。起動時にリアルタイムにスキャンしなければならないファイルとは、何なのでしょうか？スキャンしたファイルが多すぎてログを見る気にもなりません。古いパソコンには不釣り合いなセキュリティソフトになりつつあるのかもしれません。
　ときどきあるこのようなコンピュータ操作の不便さは、ESETスマートセキュリティのせいだと考えています。 タスクマネージャー を見ても、 CPU 、 メモリ ともそんなに使用していないのですが？？？初期化するのも面倒くさいし、ちょっと、思案中です。
　では、本日は、 サイバーセキュリティ経営ガイドライン をもっと踏み込んで読んでいきたいと思います。

[勘違い]
　昨日気づきましたが、 ３原則 の最後の項目は、 ステークホルダ ではなく、 IPA 、 JPCERT/CC といった、セキュリティ関係者との対話について書いてありました。DXのステークホルダと混同してしまいました。サイバーセキュリティ経営ガイドラインで想定している関係者とは以下の人達を指します。

《社内》
・CISO
・セキュリティ担当者

《社外》
・IPA
・JPCER/CC　など

などを想定しています。最新のセキュリティを実現するために必要不可欠な関係者をさしていました。

[重要10項目の詳細]
　今まで抑えていた内容だけでは、勘違い等がありそうなので、 重要10項目 についても深掘りしていきましょう！重要10項目として以下の項目を紹介しています。

【原則1：リーダーシップの発揮】
指示１：サイバーセキュリティリスクの認識、組織全体での対応方針の策定
指示２：サイバーセキュリティリスク管理体制の構築
指示３：サイバーセキュリティ対策のための資源（予算、人材等）確保
指示４：サイバーセキュリティリスクの把握とリスク対応に関する計画の策定
指示５：サイバーセキュリティリスクに効果的に対応する仕組みの構築
指示６：PDCAサイクルによるサイバーセキュリティ対策の継続的改善
指示７：インシデント発生時の緊急対応体制の整備
指示８：インシデントによる被害に備えた事業継続・復旧体制の整備
【原則２：サプライチェーンセキュリティの強化】
指示９：ビジネスパートナーや委託先等を含めたサプライチェーン全体の状況把握及び対策
【原則３：関係者との積極的なコミュニケーション】
指示１０：サイバーセキュリティに関する情報の収集、共有及び開示の促進

　サイバーセキュリティ経営ガイドラインの詳細な内容としては、どんなことをするのかそのアクションを記載し、それを怠った場合のリスクを紹介し、その対策例を挙げています。
　この冊子への全般の不満ですが、どんなことをしたらいいのか具体的なことが記載されていない点です。
　どんなプロセスを踏んで、どんなものを作り、どんな人達に、どのようなことをするかまで書けていれば、完璧だと思います。これだと、作成者が作っただけのモノになっているような気がしますが、どうなのでしょうか？
　なお、その代わりになるかどうか分かりませんが、サイバーセキュリティ経営ガイドラインの巻末に、 サイバーセキュリティ経営チェックシート 、サイバーセキュリティ対策に関する参考情報があります。

[あとがき]

　今回、文章を読みながら、まとめていきましたが、時間の都合上、最後まで読んでいなかったため、不正確な情報をブログに書いてしまいました。すみなせん。近頃ブログを休む日もあるのですが、なるべく毎日書こうとして、ちょっと無理をしていたかもしれません。今後ですが、毎日書くことを目標とするのではなく、正確な情報を提供することを目標に、情報をきちんと整理してからブログを書こうかなとしみじみと感じました(苦笑)。
　なお、サイバーセキュリティ経営ガイドラインver3.0には右記のような図があります。サイバーセキュリティ経営ガイドラインは、いろいろな フレームワーク 、規則、規範、 ガイドライン 、準則等と関係があるという話を先日しましたが、この図からも分かります。正直いうとこの当たり深い知識がありません。そのせいだと思うのですが、 中小企業診断士試験 の 経営情報システム に2年連続落ちました(苦笑)。まっ、この試験の場合、それ以外にも苦手なところがあるのですが、他の科目を優先すると、経営情報システムまで手が回りません。ただね・・・。令和5年までの過去問は、60点以上とれているのですが、そこが不思議です・・・。
　その苦手な知識なのですが、今後ブログを書くことにより補足し、仕事に試験に役立ててゆきたいと思います。

　では、また！！！

タグ： ESETスマートセキュリティタスクマネージャー CPU メモリサイバーセキュリティ経営ガイドラインサイバーセキュリティ経営チェックシートフレームワーク規則規範ガイドライン準則中小企業診断士試験経営情報システム

posted by ゼロから始めるシステム開発 at 16:39 | Comment(0) | TrackBack(0) | セキュリティ研究室

2024年10月22日

サイバーセキュリティ経営ガイドライン　−重要１０項目−　～セキュリティ研究室～

　こんにちは！
　ナビゲータのEVEです。

　昨日のやっと新システムのボリュームがなんとなくですが、分かるレベルになりました。10月いっぱいは、製造済みのクラスを、 PSR の規約へ準拠させ、11月からは、残りのクラスを作るということになりそうです。そして、翌年から、 セキュリティクラス を作りながら、それに合わせて、ログイン画面を作っていくということになります。システムを作るに際し、どうやって作っていき、どの辺を気を付けなければならないのか解説をしていく予定ですので、興味がある方は楽しみに待っていてください。内容としては、 情報処理安全確保支援士 で勉強した内容となります。それ以上は話せないということはご理解ください。
　では、早速、昨日の続きで、 サイバーセキュリティ経営ガイドライン の話しをしましょう！

[昨日は？]
　サイバーセキュリティ経営ガイドラインには、サイバーリスクを経営者が経営課題と認識し、適切な対策を講じることで、事業の継続性や信頼性を確保し、そのために守らなければならない ３原則 と、会社として実装すべき 重要１０項目 があるという話しをしました。昨日は、３原則の話しをしましたので、本日は、昨日の続きで、重要１０項目の話しをしましょう。

[重要１０項目]
　重要１０項目ですが早速その内容を見ていきましょう。以下は、「サイバーセキュリティ経営ガイドラインver3.0」からの抜粋です。

見ていただくとわかりますが、以上の重要１０項目は、３原則と対応がとれています。
　まず、原則１では、サイバーリスクを経営者が経営課題と認識し、適切な対策を講じることで、事業の継続性や信頼性を確保するために、経営者がCISOに対して指示する内容が指示１から指示８に記載されています。
　原則２、３では、事業の継続性や信頼性を確保することにあり、その事業継続性や信頼性を維持するために、指示９、１０をCISOに指示するということになります。
　なお、CISOに指示する内容としていますが、以上の１０項目の実装は、 CSIRT がいいと考えます。今回、 情報セキュリティ に関する話題として、サイバーセキュリティ経営ガイドラインを紹介したのも、CSIRTを組織化するための知識を得るためでした。
　なお、昨日原則３について、開示することへのリスクを中心に書きましたが、重要１０項目をみると、情報の収集や共有なども、関係者との積極的なコミュニケーションに含まれています。この活動自体は、CSIRTの活動に合致した部分になります。

[CSIRT]
　昨日から、CSIRTについて、書いていますが、どのような組織なのでしょうか？今回も ChatGPT に解説をしてもらいましょう！

　CSIRT（Computer Security Incident Response Team、コンピュータセキュリティインシデント対応チーム）は、組織内で発生するセキュリティインシデント（サイバー攻撃やシステム障害など）に迅速に対応し、影響を最小限に抑えるための専門チームです。CSIRTは、インシデントの予防、検知、対応、復旧までの一連の活動を行い、組織の情報セキュリティ体制を強化します。

■CSIRTの役割
?インシデント対応
　CSIRTの主な役割は、セキュリティインシデントが発生した際に速やかに対応し、被害の拡大を防ぐことです。これには、インシデントの特定、原因の分析、影響範囲の評価、再発防止策の実施が含まれます。

?セキュリティ監視
　システムやネットワークの監視を通じて、異常な活動や潜在的なセキュリティインシデントを早期に検知する役割も担います。ログの監視や脅威インテリジェンスを利用して、サイバー攻撃の兆候を発見します。

?インシデント予防
　インシデントを未然に防ぐために、脆弱性管理やセキュリティ教育、セキュリティポリシーの策定・改善を支援します。これにより、組織全体のリスクを低減します。

?インシデント後の復旧と改善
　インシデント発生後には、システムの復旧や再発防止のための対策を講じます。また、対応の過程で得た教訓を基にセキュリティ対策の改善やポリシーの見直しを行います。

■CSIRTの構築方法
　CSIRTは、各組織の規模や業種に応じて構築されます。一般的には、次のステップで設置されます。

・体制の決定: 専任チーム、兼任チーム、または外部の専門機関に委託する形式が考えられます。
・メンバーの選定: セキュリティエンジニア、ネットワーク管理者、法務担当者など、さまざまな専門家がチームに含まれます。
・運用方針の策定: インシデント対応フローや報告体制、対応の優先順位などを事前に定めます。
・トレーニングと演習: チームが迅速に対応できるよう、定期的な訓練や模擬インシデントを実施します。

■CSIRTと関連する組織
・CERT（Computer Emergency Response Team）
　CERTは、CSIRTと同様にインシデント対応を行う組織ですが、特に大規模な国や地域を対象にしたインシデント対応を行う組織を指すことが多いです。例えば、JPCERT/CCは日本の国際的なインシデント対応機関です。

・SOC（Security Operation Center）
　SOCは、ネットワークやシステムのセキュリティ状況を常に監視し、インシデントの検出と通知を行うチームです。CSIRTがインシデント対応を専門とするのに対し、SOCは監視業務に特化しています。

■まとめ
　CSIRTは、セキュリティインシデントに対して迅速かつ効果的に対応し、組織の情報資産を守るための重要な役割を果たします。組織の規模や業種に応じた適切なチーム体制を構築し、定期的な訓練やセキュリティポリシーの改善を通じて、インシデント対応能力を向上させることが重要です。

[あとがき]
　多くの場合、推定で文章を書いているのですが、本日は、断定的に書かせていただきました。なお、断定的には書いているのですが、本当のところ、行間を自分の知識でうめて記載しているので、正確なところは分かりません。自分で作ったモノではないからです。ですので、もし、疑問がありましたら、経済産業省に問い合わせてください。今回のこの資料は、こんな考え方もあるんだなぐらいで見ていただければありがたいです。

Windows について、断定的に解説をしている人がいますが、ときどき、本当か？って疑うタイミングが多々あります。自分で作ったモノでもないのに、よくそんなに断定的にしゃべれるなって・・・。Windowsって ブラックボックス 化され、かつ、複雑で、しかも、バージョンによりかなり違うという印象があるからです。そんな経験をすると、自分が作ったシステム以外は、どうしても推定で話してしまいます。サイバーセキュリティ経営ガイドラインも実は、システムとして捉えるとそんな感じになるのです。

　では、また！

タグ： PSR セキュリティクラス情報処理安全確保支援士サイバーセキュリティ経営ガイドライン CSIRT 情報セキュリティ ChatGPT Windows ブラックボックス

posted by ゼロから始めるシステム開発 at 19:25 | Comment(0) | TrackBack(0) | セキュリティ研究室

2024年10月21日

サイバーセキュリティ経営ガイドライン3.0　ー3原則ー　～セキュリティ研究室～

　こんにちは！
　ナビゲータのEVEです。

　昨日は、久しぶりに東京にいるにも関わらず、10時間以上寝てしまい、ブログの更新をすることができませんでした。ただ、そんな1日を過ごしてみて、1週間に1日ぐらいはそんな日が必要かなって感じています。今後、日曜日から月曜日に10時間ぐらい寝れる日をつくろうかなって思っています。土、日曜日は 中小企業診断士 の試験があるので、その日に休むのはリズム的にあまりよくないから、月曜日にします。
　では、そんな、日の翌日のブログですが、昨日書く予定だった、 セキュリティ に関するお話しをしましょう！

[サイバーセキュリティ経営ガイドライン]
　2022年の 情報処理安全確保支援士 のWeb研修で頻繁に出てきたキーワードに、「サイバーセキュリティ経営ガイドライン」があります。2023年度の研修はあまり出てこなかったのですが、多分、サイバーセキュリティ経営ガイドラインよりは、 DX の方が知名度が上がり、理解されやすくなったからかもしれません。ただ、その重要性は失われたわけではなく、2015年12月28日に初版が出稿されてから、ver3.0は、2023年3月にリリースされ、今なお企業におけるセキュリティに重要な役割を果たしていると思われます。
起業に際し、 CSIRT を導入しようと考えています。そのCSIRTを実践しようとした場合、非常に重要なガイドラインです。そのため、このブログで サイバーセキュリティ経営ガイドライン を勉強するのと同時に、知識を共有したく今回紹介することにしました。

[サイバーセキュリティ経営ガイドラインとは？]
　サイバーセキュリティ経営ガイドラインの対象は、日本国内のすべての企業です。そして、その中でも、タイトルからも分かるように、経営者をターゲットにして策定されました。
　その内容は、サイバーリスクを経営者が経営課題と認識し、適切な対策を講じることで、事業の継続性や信頼性を確保することにあります。具体的には、「 3原則 」、及び経営者が情報セキュリティ対策を実施する上での責任者となる担当幹部（CISO等）に指示すべき「 重要10項目 」がまとめられています。

[サイバーセキュリティ経営ガイドラインの3原則]
　サイバーセキュリティ経営ガイドラインの3原則は、企業経営リスクへの対策を検討、議論するにあたり、考慮すべき原則が記載されています。以下は、経済産業省から出ている、サイバーセキュリティ経営ガイドラインからの抜粋です。

?経営者は、サイバーセキュリティリスクが自社のリスクマネジメントにおける重要課題であることを認識し、自らのリーダーシップのもとで対策を進めることが必要
?サイバーセキュリティ確保に関する責務を全うするには、自社のみならず、国内外の拠点、ビジネスパートナーや委託先等、サプライチェーン全体にわたるサイバーセキュリティ対策への目配りが必要
?平時及び緊急時のいずれにおいても、効果的なサイバーセキュリティ対策を実施するためには、関係者との積極的なコミュニケーションが必要

LRM株式会社のサイトには、以下のような形で要約されています。

?リーダーシップの発揮
?サプライチェーンセキュリティの強化
?関係者との積極的なコミュニケーション

　?のリーダーシップンの発揮は、 情報セキュリティガバナンス で記載されている通り、情報セキュリティ対策の透明性を向上しその責任が経営層にあると定義しています。その定義されたその内容を主導権を持って実施するということを意味しているのだと思われます。
　?は、あまり世間一般には知られていないのですが、親(大)会社が狙われる手口として多いのが、 サプライチェーン攻撃 だと言われています。どんな攻撃か端的に言うと、子会社から親(大)会社を攻撃するといったものになります。なんで子会社からかというと、親会社は、セキュリティについても十分に費用をかけ、社員教育も十分し、攻撃するには、かなりハードルが高くなっています。しかし、子会社は、資金的にも、時間的にも親(大)企業ほどかけることができず、攻撃者からすると攻撃しやすいのです。そんな親と子の間のネットワークは通常つながっています。そのため、子会社から親(大)会社への攻撃が成立してしまうのです。その攻撃名が、サプライチェーン攻撃と言われています。その攻撃を念頭に入れた1原則だと思われます。
?は、ステークホルダ及び社会への姿勢だと思います。これなのですが、その内容によっては、攻撃のトリガーになる可能性があります。そのため、「 ISO 27001 」や「 NISTフレームワーク 」などのセキュリティ基準に準拠しているなど、準拠している基準や、会社の体制にとどめるべきだと思われます。
　?は、最新のセキュリティを実装するために必要不可欠な、関係者を指します。それは、CISOのみならず、社内のセキュリティ関係者、外部では、IPA、JPCERT/CCを指します。その関係者の人たちと、緊密なコミュニケーションをとることを求めています。

[あとがき]
　情報セキュリティガバナンス、ISO 27001、NISTフレームワークなど、いろいろな規約、ガイドラインなどがからみあっていて、非常に説明しにくいのですが、その部分については、後日解説をします。ここでは、いろいろなフレームワーク、基準、規約、ガイドラインがあり、いろいろ関連しあっているとぐらいの理解でいいと思います。調べていくうちに、目から鱗なんてことがあるかもしれません。
　情報処理安全確保支援士の試験でも出題されるのですが、フレームワーク、基準、規約、ガイドラインなどの識別がむずかしく、どれにどんなことが書かれているのか覚えるのに非常に苦労した記憶があります。情報処理安全確保支援士の試験では、概要とその違いぐらいしか覚えていませんでしたが、この場をかりて、深い知識にできればと考えています。

　では、また！！！

■サイバーセキュリティ経営ガイドラインとは？その内容を徹底解説(LRM株式会社)
https://www.lrm.jp/security_magazine/cybersecurity_guideline/

■サイバーセキュリティ経営ガイドラインver3.0(経済産業省)
https://www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf

タグ：起業サイバーセキュリティ経営ガイドライン CSIRT DX 情報処理安全確保支援士セキュリティ中小企業診断士 ISO 27001 サプライチェーン攻撃情報セキュリティガバナンス NISTフレームワーク

posted by ゼロから始めるシステム開発 at 15:40 | Comment(0) | TrackBack(0) | セキュリティ研究室

2024年10月19日

独習PHP第4版　～プログラム研究室～

　こんにちは！
　ナビゲータのEVEです。

　今日も、 独習PHP第4版 について目を通しています。前回この本を読んだときは、必要な所だけ目を通したので、641頁ある本のほとんど読んでいなかったようです。4,000円近く支払って購入したのに、もったいないモノです。

独習PHP 第4版 [ 山田祥寛 ]

価格: 3740円
(2024/10/19 14:31時点)
感想(2件)

　独習PHP第4版ですが、毎日PDFでのページ数で、50頁読むことにしました。それ以上だと他の作業への負担が増しますし、その範囲内だと集中して読むことができそうだからです。PDFの頁数で、671頁あるので、14日ぐらいで読めそうです。そのぐらいだと、起業の検討も終わり、会社が設立されている可能性があるので、ちょうどよいかもしれません。
　そんな独習PHP第4版ですが、やはり、目新しい情報がいくつかありましたので、報告させて頂きます。

[Just-In-Time]
Just-In-Time （以降JIT）って知っています？トヨタカンバン方式で利用されているものではありません。これ、 PHP8 からあらたに加わった機能です。
　PHPは インタプリタ言語 だと多くの人が知っていますが、PHP8からは、インタプリタ言語とは言えなくなるような機能が追加されました。それが、 JIT です。
　インタプリタ言語は、毎回1行ずつ翻訳しますが、JITは内部的に一括翻訳します。一括翻訳されたコードはメモリ上に保存して再利用されるので、実行効率が大幅に向上します。その向上した性能は、以前の3倍という計測もあるぐらいです。もし、PHP8以前で運用しているグループがあるのでしたら、PHP8へバージョンアップすべきでしょう！

[BOM]
　以前のブログで、PHPのコーディング規約を紹介しましたが、その中で、「 文字エンコーディング：ファイルはUTF-8 without BOMを使用すること。 」という記述があります。それは、 PSR の規約を踏襲したモノなのですが、どのようなものなのでしょうか？ ChatGPT に聞いてみました。

　Byte Order Mark (BOM) とは、テキストファイルの先頭に置かれる特別なバイトシーケンスで、ファイルのエンコーディングやバイト順序を示すために使用されます。BOMは主に UTF-8, UTF-16, および UTF-32 のエンコーディングで利用されます。

■BOMの主な目的
?エンコーディングの識別:
　BOMは、テキストファイルがどのエンコーディングで保存されているかを示すために使われます。たとえば、UTF-8では EF BB BF の3バイトがBOMとして使われます。

?バイト順序の指定:
　UTF-16やUTF-32では、BOMがバイト順序を指定します。例えば、UTF-16では、リトルエンディアン（LE）の場合は FF FE、ビッグエンディアン（BE）の場合は FE FF となります。

■代表的なBOMのシーケンス
・UTF-8: EF BB BF
・UTF-16 LE: FF FE
・UTF-16 BE: FE FF
・UTF-32 LE: FF FE 00 00
・UTF-32 BE: 00 00 FE FF

■使用上の注意
　BOMがあることで、ファイルのエンコーディングを自動的に識別できるため、特に異なるエンコーディングのファイルを扱う際に便利ですが、いくつかの注意点があります。
　一部のプログラムやシステムは、BOMを正しく処理できない場合があり、表示や処理に問題を引き起こすことがあります。
　BOMが含まれるファイルを処理する場合、余分なバイトが出力されたり、ファイルの先頭に不必要な文字が現れることがあります。

■まとめ
　BOMは、エンコーディングの識別やバイト順序の指定に役立つ特殊なバイトシーケンスです。テキストファイルの互換性や正しい解釈を確保するために、BOMの存在とその影響を理解しておくことが重要です。

一部のプログラムやシステムでは正しく処理されないという記述がありますが、PHPもその中に含まれます。PHPプログラムを BOM ありで保存すると、以下のような誤動作が発生します。

1)プログラムエラー
2)文字化け
3)セッションやクッキーの障害
4)ファイルの互換性の問題
5)パフォーマンス

以上も、ChatGPTから聞いた内容なのですが、BOMをつけてPHPプログラムを保存すると大きな問題が発生しそうです。なお、私が愛用している、秀丸ですが、デフォルトBOMは付けない設定です。そのため、今までこのようなことで困ったことはありません。

[あとがき]
　この間、 静的メソッド の話をし、その関連情報として、 静的プロパティ について話しましたが、それ以外に 静的変数 というのもあるようです。その部分に関して言うと、かなり混乱しています。現在のペースで読み続けていくと、今日から5日後に当該頁に達し、そのときに詳細な報告ができると思います。

　機能が違うものに名称を付けるとき、明らかに違う名前で付けてもらえるとありがたいと思ったのは私だけでしょうか？

　では、また！！！

タグ： BOM 静的変数 PHP8 インタプリタ言語静的プロパティ秀丸 JIT ChatGPT PSR 静的メソッド独習PHP

posted by ゼロから始めるシステム開発 at 14:29 | Comment(0) | TrackBack(0) | プログラミング研究室

2024年10月18日

EVEシステムの開発　～システム開発研究室～

　こんにちは！
　ナビゲータのEVEです。

　今日のシステム開発はお休みです。
　午前中、 PHP の本を50頁ほど読み、収穫としては、 Vue.js という技術について知ったこと・・・。
　Vue.jsとは、Vue.jsダウンロード後、サーバーからデータをダウンロードして、クライアント側で画面を生成するという フレームワーク になるそうです。そのような技術のため、 HTML (Vue.js含む)自体は1度きりダウンロードし、それ以降は、画面を構成するデータのみのダウンロードなので、通信速度が速いというメリットがあります。PHPと直接関係ないのですが、興味を引かれました。最初のリリースは、今から10年前の2014年で、最新版は、2020年9月18日にリリースされた、ver3.0になるそうです。本日早速図書館へ予約し、読んで自分のサイトで利用できそうなら研究対象としたいと考えています。なお、担当研究室は、 プログラム研究 室です。

[案件検索中]
　PHPの開発としては、本日、本を読んだだけで終えてしまいましたが、一応、今年の12月で、現在製造している API を完成させたいと考えています。それ以降は、実際にフレームワークの製造に入ります。そんな、プロジェクトの進行状況なのですが、そのプロジェクトを前に進めるために、資金源を確保するための準備を進めています。インターネットで仕事を紹介しているサイトが複数あるのですが、そのサイト案件を受註し、資金を得ようと考えています。

[インターネットからの受註]
　本日登録したのは、 クラウド・ワークス ・・・。 マーケティング を兼ねて登録しようとしたのですが、会社の登記の番号と言ったらいいのでしょうか？それと社印がないと、法人として登録できないようです。どの形態で会社設立しようか、現在検討中で、登録予定も現時点未定です。だから、マーケティングがてら、個人名で最初登録してどんな感じか感触を得てからとも現在考えています。
システム開発 だと、めんどくさそ～っなことがたくさん出てくるのですが、 プログラム開発 ならそんなにめんどうなことはないかなとは思っているのですが、どうでしょうか？何があるか分かりませんからね・・・。

[サラリーマン時代の記憶]
　サラリーマンで経験した最後の方のプロジェクトは、かなり厳しい状況でした。新入社員の時のような、まっさらな プロジェクト はほとんどなく、資金が足りず、システムも作り直した方が早いかもしれないといったプロジェクトがほとんどでした。一般的にそれを火消しというのですが、そんなプロジェクトで工夫してできる事は限られており、やることはほぼ決まっています。ただ、やるべきコトをやっていなかったプロジェクトが多いような気がしましたが、気のせいでしょうか？
　そんなプロジェクトばかりではないと思うのですが、今年だったか、去年だったと思いますが、聞いた情報だと、現在、 プロジェクト成功率は3割 だというのです。確か、私がいたときは 5割だったような気もするのですが・・・。そんな状況を聞くにやはり、二の足を踏んでしまいます。

[あとがき]
　以上のような状況で、正式なシステムへの登録はちょっと待とうかと思います。 無限責任 のまま仕事をする勇気はありません。よくある話なのですが、責任を取るのが責任者のはずですが、その責任を、外注とか、外部に押しつけるといったことがあります。そんな不誠実な組織ばかりではないのは知っていますが・・・。
　心配性な自分の性格がうらめしくもありますが、もうしばらく辛抱したいと思います。

　では、また！！！

タグ： php Vuejs フレームワーク html プログラム研究 API クラウドワークスマーケティングシステム開発プログラム開発プロジェクト

posted by ゼロから始めるシステム開発 at 19:28 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月17日

静的メソッド・静的プロパティ　～プログラム研究室～

　こんにちは！
　ナビゲータのEVEです。

　ブログを書く方法として、大きく分けて2つあります。
　1つは、前調べをきちんとしてから目的をもって、ブログを書く方法・・・。
　もう一つは、なんか、疑問があり、その疑問を解決するために、調べながらブログを書く方法・・・。
　どちらも、知識を整理し、後で見返すことができるというメリットがあります。前者は、結論を予め決めて書き出すのですが、後者は、最初どんな結末になるのか全く分かりません。そんな後者ですが、普段だったら、深掘りするのは面倒くさいようなものまで、詳細に調べることができるというメリットがあります。だから、このブログでは、後者の書き方を多用します。ただ、2024年10月15日の「 システムエンジニアが目指す中小企業診断士 」は、おかしな内容になってしまいました。
　まっ、そんなこともあるのですが、本日も後者の方法で、 PHPプログラミング について書きます。

[独習PHP第4版]
　本日は、PHPの クラスメソッド についてまず最初にかきましょう！ Java は自分が整理した資料を読み直してみましたが、それにより思い出すことができました。しかし、PHPは、 オブジェクト指向言語 としてプログラミングするのは初めてですし、その中でクラスメソッド、 静的メソッド があるなんてことも、つい先日知りました。多分、Javaと同じじゃないかなとは思うのですが、想像でプログラミングするわけにはいけないので、以前購入した、「独習PHP第4版」から同記述を探したいと思います。

独習PHP／山田祥寛【3000円以上送料無料】

価格: 3740円
(2024/10/17 15:21時点)
感想(0件)

　よく考えたら、最初必要な所だけ斜め読みしてから忘れていましたが、頁を開くのは久しぶりです。なぜそのようなことになっているかというと、ほぼ理解できているということもありますが、 AI の力が大きいでしょう！ただ、AIもときどきおかしい回答をすることもあり、総合的な言語知識は必要不可欠だと思われます。これを、機会にまた本を読み直したいと思います。
　この本ページ総数641頁です。全部読んでからプログラミングするのは時間がかかるので、必要なところだけ斜め読みしてシステムを開発したのですが、ここにきて、本の重要性を再認識しています。

[クラスメソッド]
　では、早速例を見て行きましょう！以下は、 ChatGPT に御願いして作ってもらったClassです。


class MyClass {
public static $staticVar = 'Hello, World!';

public static function staticMethod() {
return 'This is a static method.';
}
}

echo MyClass::$staticVar; // 'Hello, World!'と出力 

echo MyClass::staticMethod(); // 'This is a static method.'と出力

ここで背筋に凍るようなものを感じたのは、 静的プロパティ ・・・。これ、オブジェクト指向言語で書き始めた頃、多用していましたね・・・。理由は、変数の意味を明確にしたかったから・・・。そのため、メソッド内で定義した変数は static をつけて定義をしていました。それが実は、静的プロパティとして利用しようとしていたとは・・・。
　変数は、クラス内で自由に参照するのはいいのですが、それ以外から閲覧するのは正直問題ありと考えています。そのため、メンバー変数は私が作るプログラムではすべて private です。Javaだと public static void main() なんて記述でよく見ますが、現在すべての言語非常に似ていると言うことを再認識しないといけないようです。
　現在は、すべて書き換えているのですが、無知とは怖いモノです。
　ちなみに、今まで、 メンバー変数 を クラス変数 と言った言い方をしましたが、Javaだと、クラス変数とは静的プロパティを指します。PHPでは、クラス変数＝静的プロパティではないらしいですが、以降は、メンバー変数という言い方をします。ただ、 クラス定数 という言葉もあり、これは、Java、PHPとも同じ意味で使用され、メンバー変数とともに記述される定数です。 JavaScript と同様に、 const で宣言します。そろそろ、頭が混乱してきました(笑)。
　なお、以上の例ですが、使い方は、Javaとあまり変わりがないようです。

[あとがき]
　調べ始めて思いましたが、やはり、きちんと本を読み直した方が良いようです。「独習PHP第4版」は最後まで読めていないので、初めて読む章もあります。まず、最初ざっと読み、知識として不足してそうなところを深掘りするスタイルで学習を進めたいと思います。
　AIをサポーターとして利用するのはいいのですが、AI主体で作るプログラミングの危険性を近頃感じています。お互い気をつけましょう！

　では、また！！！

タグ： php クラスメソッド Java オブジェクト指向言語静的メソッド AI ChatGPT 静的プロパティ static private メンバー変数クラス変数クラス定数 JavaScript const

posted by ゼロから始めるシステム開発 at 15:11 | Comment(0) | TrackBack(0) | プログラミング研究室

2024年10月14日

静的メソッドって？　～プログラム研究室～

　こんにちは！
　ナビゲータのEVEです。

　本日、奥様と一緒に 司法書士 の方にあってきました。面談理由は、どの組織形態で起業したらいいのかという相談です。この場で何回か起業について書いてきました。その時の内容としては、 LLP ( 有限責任事業組合 )について興味があり、それで起業したいという話をしていたのですが、本日司法書士の方と話したところ、ちょっと、心動いています。
　LLP（有限責任事業組合）は、ず～っと、組織変更しない場合は利益があるのですが、組織変更を念頭にいれると、魅力が薄れます。もし、最終組織形態が、 株主会社 なら設立当初から、株主会社にした方がメリットが大きいようです。ただ、株主会社になった場合の収益を考えたら、そのメリットとは 雀の涙 ぐらいのような気がするのですが・・・？ 捕らぬ狸の皮算用 をしていますが、事務手続きの苦労などをも含め一ヶ月ぐらいをめどに結論を出したいと思います。
　それでは、今日は、プログラム研究室から、 静的メソッド と インスタンスメソッド の違いについて書かせて頂きます。

[今まで忘れていた静的メソッド？]
　静的メソッドって知っている人います？忘れていたのですかね？ ChatGPT とプログラムをデバックをしていて、初めて聞いたような気がします。以前Javaの試験で使用した資料に目を通していますが、ないようです。本当になかったかどうか微妙なのですが・・・？
　では、静的メソッドとはどのようなモノでしょうか？ChatGPTに聞いてみます。

■静的メソッド（static method）
★定義
　静的メソッドは、クラスに直接属するメソッドで、インスタンスを作成せずに使用できるメソッドです。クラスそのものに関連する機能を提供します。

★特徴
　クラス名を使って呼び出します（インスタンスを必要としない）。
　通常、static キーワードで定義されます（言語によって異なりますが、例えばPHPやJava、C++ではstaticを使用）。
　静的メソッドの中では、インスタンス変数（オブジェクト固有の変数）を参照できず、静的変数（クラス共通の変数）のみを操作できます。

　はっきり言って、静的メソッドでの製造は、従来の構造化プログラミングなどプログラムと同じような感じです。だったら、なんで、インスタンスメソッドなんかあるのだろうという疑問が浮かび、それについて、ChatGPTに聞いてみました。

　インスタンスメソッドが存在する理由は、オブジェクト指向プログラミング（OOP）の核心となる「状態管理」や「柔軟性」にあります。以下、インスタンスメソッドが必要とされる理由について詳しく説明します。

?オブジェクトごとの状態を管理するため
　インスタンスメソッドは各オブジェクトの固有の状態（プロパティ）にアクセスして操作するために存在します。オブジェクト指向の基本的な考え方は、実世界の物体や概念をプログラム内でモデル化することにあります。例えば、異なる「車」オブジェクトを扱う場合、各車にはそれぞれの状態（色、速度、燃料量など）が異なるため、インスタンスごとにこれらの状態を管理しなければなりません。

?カプセル化とデータの隠蔽
　オブジェクト指向では「カプセル化」という概念が重要で、これはデータ（プロパティ）を隠し、直接アクセスさせないようにするための仕組みです。インスタンスメソッドは、オブジェクトの内部状態を安全に管理・操作し、外部からの直接操作を防ぎます。このように、データにアクセスするための専用メソッド（getterやsetter）を提供することで、セキュリティやデータの整合性が保たれます。

?柔軟性と拡張性
　インスタンスメソッドは多態性（ポリモーフィズム）を活かして、同じメソッド名でも異なる動作を持たせることができます。これにより、各オブジェクトのクラスに応じて異なる振る舞いを実現できます。静的メソッドではこの柔軟性が制限され、特定の動作に依存した設計になりがちです。

?オブジェクト同士の相互作用を実現するため
　インスタンスメソッドは、複数のオブジェクトが相互にやり取りしながら状態を変化させるような複雑な動作を実現するために必要です。オブジェクト同士の関係を持ち、個々のオブジェクトが他のオブジェクトと連携するシステムを構築する際、インスタンスメソッドが役立ちます。

■まとめ
・インスタンスメソッドの必要性は、プログラムにおけるオブジェクトごとの状態管理や、複雑な相互作用を柔軟に実現するためです。特に、オブジェクト指向の基本的な概念である「カプセル化」や「多態性（ポリモーフィズム）」を活用する際に重要です。
・静的メソッドは便利である一方、柔軟性や個別の状態管理が必要なケースではインスタンスメソッドが不可欠です。

以上について、意訳すると、いろいろな人がプロジェクトに参加することを考える場合、従来のプログラム手法(静的メソッドのような開発手法)より、オブジェクト指向言語での開発が効率的、拡張的だということだと思います。

[あとがき]
　Javaの資格は、2016年に Bronze 、2017年に Silver を取得し、そのまま放置していました。まっ、インターネットから仕事をしてもよかったのですが、実務を経験したことがないということがためらいの原因となりました。だったら、 PHP 、 JavaScript 、 HTML などなどいろいろあったのですが、昔ながらのプログラマとしては、自分のプログラム開発手法を自分のシステムに適用するのは問題ないのですが、他のシステムに適用していいのかどうか悩みました。そんな悩みを解消してくれたのが、ChatGPTです。自分が作ったプログラムを元に、最新のソースに変換してくれるのです。自分の名誉のために言うと、そんなに大きくは違いません。但し、ChatGPTから提供されたロジックは、 目から鱗な点 が多々あります。そんなAIの力を利用できるのと同時に、新型コロナ感染症の数年を通して、 リモートワーク が普通になったという点も大きいでしょう。
　今まで、 SNS や、株とかもやってきましたが、 エフェクチュエーション 的な考え方で言うと自分でコントロールできないことはビジネスにならないということは、この数年身をもって知りました。
　そんな状況で、私が考える環境が揃い、かつ、ブログを通して個人的な悩みを話してきましたが、それも、このブログを多くの人に見て頂いたことにより解消しつつあるような気がします。
　今まで、引きこもりのような生活だったのですが、これから、一歩前に出ます。

　では、また！

追伸・・・。
このブログを書き終えて、もしかして、静的メソッドには、別な言い方があるのでは？っということで探したところありました。 クラスメソッド です。クラスメソッドで資格を取得した時の本を調べてみると、ありました・・・。勉強していたのですね・・・。忘れていただけでした・・・。ここ1、2年オブジェクト指向でプログラミングしていますが、脳裏にさえ出てきませんでした。来年 JavaGold の試験を受けますが、Bronze、Silverでの勉強の復習をしたいと思います。

■起業のリスクヘッジについて考える　～システム開発研究室～(2024年10月1日)
https://fanblogs.jp/bahamuteve/archive/496/0

■LLPとは？　～システム開発研究室～(2024年10月2日)
https://fanblogs.jp/bahamuteve/archive/497/0

posted by ゼロから始めるシステム開発 at 17:32 | Comment(0) | TrackBack(0) | プログラミング研究室

2024年10月12日

JavaScriptコーディング規約　～プログラム研究室～

　こんにちは！
　ナビゲータのEVEです。

　昨日は、 PHP の コーディング規約 について紹介しましたが、本日は、 JavaScript のコーディング規約について紹介したいと思います。
　ただ、先ほどまで全く考えていなかったので、まずは、 ChatGPT に、 Google JavaScript コーディング規約を調べてもらおうと思います。

[Google JavaScriptコーディング規約]
　2024年9月12日に、EVE VProjectのJavaScriptコーディング規約を、どこのコーディング規約に揃えるかという話しをしました。その検討の結果、Googleになったのですが、決まったことだけを報告しどのようなコーディング規約にするのか検討・報告していませんでした。まっ、この検討をしている時には既に、既存のJavaScriptをすべてクラス変換した後だったので、今までは検討する必然性がなかったからなのですが・・・。ただ、昨日PHPのコーディング規約を決めた結果を、ChatGPTに評価してもらったところ、PHP、JavaScript双方に関連する変更点が出てきたため、今回、JavaScriptの検討をすることにしました。
　それでは、早速Googleのコーディング規約について、ChatGPTに聞いてみましょう！

　GoogleのJavaScriptコーディング規約は、コードの可読性と一貫性を高め、チームでの共同作業をスムーズに進めるためのルールセットです。以下に、主要なポイントを詳細に説明します。

?スタイルとインデント
1)インデント: 2スペースを使用します。タブは使用しません。
2)行の長さ: 1行の長さは最大80文字までに制限します。ただし、例外として長いコメントや長い文字列がある場合は、最大120文字まで許容されます。

?変数の宣言
1)constとletの使用:
2)可能な限りconstを使用し、再代入する必要がある場合のみletを使用します。
3)varは使わず、ES6で導入されたconstやletを推奨します。
4)スコープ: 変数は可能な限り宣言のスコープを限定します。グローバル変数は避け、ブロックや関数スコープ内で定義します。

?命名規則
1)変数名や関数名: キャメルケース（例: camelCase）を使用します。
2)クラス名: パスカルケース（例: PascalCase）を使用します。
3)定数: 定数は全て大文字でアンダースコアで単語を区切ります（例: MAX_COUNT）。

?関数のスタイル
1)矢印関数: 短い関数は、ES6の矢印関数（=>）を使って簡潔に記述します。
2)関数の宣言と式: 宣言形式（function foo() {}）と関数式（const foo = function() {}）の両方が使用されますが、必要に応じて使い分けます。矢印関数は短く、thisをバインドする必要がない場合に推奨されます。

?オブジェクトと配列のリテラル
1)オブジェクト: オブジェクトリテラルは短縮プロパティ名やメソッドの略記法を使用します。
2)配列: 配列リテラル（[]）を使用します。new Array()は使いません。

?コメント
1)ブロックコメント: 複数行の説明が必要な場合は、/* */を使ってブロックコメントを書きます。
2)行コメント: 1行コメントは//を使用します。
3)JSDoc: 関数やクラスにはJSDoc形式でドキュメントコメントを追加し、パラメータや戻り値を記述します。

?クラスとメソッド
1)クラス名はパスカルケースで記述します。
2)プライベートメソッドやフィールドには、ES2020で導入された#記号を使います（例: #privateField）。
3)コンストラクタでクラスのフィールドを初期化します。

?エラーハンドリング
エラーハンドリングにはtry-catchを使用し、エラーオブジェクトに詳細な情報を含めます。

?セミコロンの使用
1)JavaScriptは自動セミコロン挿入（ASI）機能を持っていますが、明示的にセミコロンを付けることが推奨されます。

?イミュータブル性
1)可能な限りオブジェクトや配列はイミュータブルに保ち、Object.freeze()やスプレッド演算子（...）を使ってコピーを作成します。

?テンプレート文字列
文字列の結合には+ではなく、バックティック（`）を使ったテンプレートリテラルを使用します。

?ES6+ 機能の使用
1)ES6以降で導入された機能（例: const, let, アロー関数、テンプレートリテラル、classなど）を使用します。
2)importとexportを使ってモジュールを分割し、コードをモジュール化します。

意味不明な記述もあるのですが、この規約を、昨日作ったPHP規約とマージします。

[Google JavaScriptコーディング規約とEVE VProjectPHPコーディング規約のマージ]
　以下が、Google JavaScriptコーディング規約とPSRをもとにして作成した、EVE VProjectのJavaScriptのコーディング規約です。やはり、Google JavaScriptコーディング規約と PSR は、似ているといった印象です。JavaScriptもPHPもどちらも、秀丸で製造しているので、間違えてしまいそうです。
　まだ、明確に理解していない点が多々あるため、暫定的な規約だとご承知ください。

【クラス】
★Class機能概要
・1ファイル1クラスで記述する
・1要素、1インスタンスで処理をする。
→処理対象の要素1つに対して、1インスタンスで操作する。

★クラス命名規約
・パスカルケースで記述する。
・クラス名の最後にClassとつける
・ファイル名と同一名とする。

★クラス記述規約
・クラスの開始ブレース（{）は、クラス名の次の行に配置します。
・クラスのプロパティとメソッド間には、1行の空行を挿入します。
・引数は1行ずつ記述し、70バイト目にその名称を記述する。

★クラス変数
・コンストラクタでクラスのフィールドを初期化します。

【コンストラクタ】
★コンストラクタ機能
・引数は必ず入力データチェックを行う。
・引数として取得した値は、クラスの変数として設定する。
・Classの特性をよく理解し、取得した引数のプロパティ情報を取得し、クラス変数として管理する。

【メソッド】
★メソッド機能
・引数は必ず入力データチェックを行う。
・正常時には目的の値を返却するが、異常の場合は、必ずfalseを値として返却する。
・異常時の詳細な情報は、クラス変数として管理し、必要に応じて内容を確認できるように製造する。
・異常時の場合は、処理の途中で中断できるが、正常な場合は、メソッドの最終行で値を返却する。
・返却値としてメソッド内で共通の変数を利用した場合、rtnとする。

★メソッドの記述
・引数は1行ずつ記述し、70バイト目にその名称を記述する。
・メソッド内使用変数はメソッドの先頭にすべて記述する。
・変数名は、変数名のみを記述し、場合によって、初期化する。
・メソッドの開始ブレース（{）は、メソッド名の次の行に配置します。
・メソッドの引数リストが長い場合、複数行に分けることができます。この場合、各引数は新しい行に配置し、カンマで区切ります。
・返却値の型は引数と行を別にする。
・返却値の型はメソッドの{と同じ列に記述する。

★メソッド命名規約
・キャメルケースで記述します。
・privateメソッドの場合先頭に、#をつける。

【関数】
・HTML内JavaScriptは、function関数で製造します。
・矢印関数: 短い関数は、ES6の矢印関数（=>）を使って簡潔に記述します。
・関数宣言は矢印関数を推奨します。特にコールバックや匿名関数には矢印関数を使います。
・名前のある関数には function キーワードを使うこともありますが、通常は const を使い、矢印関数を利用します。

【プロパティ】
・キャメルケースで記述します。

★クラス変数機能
・クラス変数の設定は、同一クラス外から設定する場合、setメソッドを製造する。
・クラス変数の取得は、同一クラス外から取得する場合、getメソッドを製造する。

★クラス変数命名規約
・privateプロパティの頭に#をつける

★定数
・定数名：定数名はすべて大文字で、単語の区切りにアンダースコア（_）を使用します。

★メソッド内変数
・メソッド内の処理結果を格納する変数は、何も制約がない場合ansにする。
・Boolean変数には is、has、should などのプレフィックスを付けて、真偽値を表していることが明確になるようにします。
・プライベートプロパティには先頭に#をつけて、他のコードから直接アクセスしない意図を示します
*プライベートプロパティとは、PHP、Javaでいうprivate変数を指します。
・var は使わず、const または let を使う。const は再代入されない変数に使い、let は再代入が必要な変数に使います。

【文字列】
・文字列は必ずシングルクォート（'）を使用します。テンプレートリテラル（バッククォート）は、変数を含める場合に使用します。

【コメント】
・JSDoc: 関数やクラスにはJSDoc形式でドキュメントコメントを追加し、パラメータや戻り値を記述します。
/**
* This method sets the error message.
*
* @param string $errMsg Error message to set
* @return bool True on success, False on failure
*/
・クラス、メソッドのヘッダには、以下の内容を記述する。
┣ Class Name(クラス名)
┣ Function Name(メソッド名)
┣ Parameters(引数)
┣ Return Value(返却値)
┃┣ On Success(正常時)
┃┗ On Failure(異常時)
┣ Author(製造者)
┣ Creation Date(製造年月日)
┣ Update Date(更新年月日)
┣ Release Date(リリース日)
┣ Version(バージョン)
┣ Summary(概要)
┣ Remarks(備考)
┗ Notes(注意)概要　←　必要に応じて
・コメントを1行で記述する場合は、同コメントは次行のプログラムを機能を説明するものでなければならない。
・コメントは、70バイト目から記述する
┗70バイト目から記述するコメントは、変数等の名称でなければならない。
・コメントの内容とプログラムが矛盾がないように記述する。
・コメントを//で記述する場合、//の後に1バイトスペースを挿入する。

【オブジェクト・配列】
★配列の記述
・配列はショート配列構文 ([]) を使用します。
・配列が複数行にまたがる場合、各要素は新しい行に配置し、インデントします。
・配列は複数形の名前を使うことが推奨されています。これは配列に複数の要素が含まれることを意味するためです。

★配列処理
・forEach, map, filter, reduce など、組み込みの配列メソッドを積極的に使用します。
・可能な限りオブジェクトや配列はイミュータブルに保ち、Object.freeze()やスプレッド演算子（...）を使ってコピーを作成します。

★オブジェクトと配列
・オブジェクトリテラルや配列リテラルを使用する。
・オブジェクトプロパティや配列要素は適切なインデントで記述します。
*人の体と言ったら、頭、手といった形で変数を作るのではなく、配列で表現するという意味らしい？

【例外処理】
★例外処理
・例外処理は、try～catchで記述し、エラーの場合は処理を終了する。

★例外処理の記述
・try、catch 句の開始ブレースは、同じ行に配置します。
・catch 句は、前の try ブロックと同じインデントレベルで記述します。

【デストラクタ】
・クラス変数をすべて初期化する。

【共通記述方式】
・＝(イコール)の位置は、できるだけ、コンストラクタ内、メソッド内で先頭から同じ位置に記述する。
・if文で判定する場合、判定条件は1行ずつに記述し分かりやすく記述する。
・ファイルの終了行
┗ファイルの最後には必ず空行を1行入れます。
・キーワードや制御構造のスタイル
┣キーワード（if、else、while、switch など）の後には、スペースを入れます。
┣制御構造の条件式の前後にはスペースを入れます。
┣開始ブレース（{）は同じ行に配置します。
┗switch 文の case と default は、インデントされませんが、その内部のコードはインデントされます。break ステートメントは case 内でインデントします。
・常に文の終わりにセミコロンを付けます。
・ブロック内の文は必ず {} で囲みます。複数行の if や else の条件式には適切なインデントを使用します。
・ES6（ECMAScript 2015）以降の新機能を積極的に利用します。特に、const や let、arrow functions、class、template literals、destructuring などを使います。
javascript
・最大80バイトとするが、80バイトを越える場合120バイトまで許容する。
・120バイトを越える場合改行して記述する。

【インデント】
・1インデント、2バイトとする。

[あとがき]
　昨日、ChatGPTに指摘された部分を、JavaScriptに取り入れました。 クラス ヘッダ、 メソッド ヘッダの部分なのですが、PHPもJavaScriptも同じ記述方法なので、ここは揃えるまでもなく、既に製造した、EVEシステムを変更すべきでしょう？JavaScriptを1クラスこの仕様に基づいて作り変えた見たのですが、文字列置換だけで何とかなりそうです。
　ブログをアップロード後、ちょっと休んでから、ChatGPTでのデバックをしながら、修正したいと思います。その前に、昨日公開したPHPのコーディング規約を修正する方が先ですか？

　では、また！！！

■JavaScriptの世界標準規約　～プログラム研究室～2024年9月12日)
https://fanblogs.jp/bahamuteve/archive/488/0

タグ：秀丸 php コーディング規約 PSR ChatGPT Google JavaScript

posted by ゼロから始めるシステム開発 at 16:13 | Comment(0) | TrackBack(0) | プログラミング研究室

2024年10月11日

プログラム改修　～プログラム研究室～

　こんにちは！
　ナビゲータのEVEです。

　毎日、午前 中小企業診断士 の勉強をした後、午後ブログとプログラム製造をしています。
　プログラム製造は、新規で クラス を作ることは少なく、 ChatGPT にデバックしてもらったプログラムを修正しながら、 PSR に準拠した、新プログラム規約へ適合させる作業を実施しています。

[ChatGPTでのデバック ]
　今までは、プログラムの製造中心にやってきましたが、ここへきて、作ったプログラムをChatGPTにデバックしてもらっています。理由は、 JavaScript のデバックで分かりましたが、クラス全体が完成していなくても、 メソッド 単体でデバックできることが分かったからです。それと、ChatGPTは、デバックするプログラムの長さに制約があります。短いクラスならいいのですが、長いステップのものだとデバックはできません。デバックしたい部分に関連しない プロパティ 、メソッドを削除してからデバックしようとも考えましたが、めんどくさいのでデバックは二の足を踏んでいました。
　ただ、メソッド単体でデバックする場合、同一クラスで利用する、プロパティ、メソッドは省略した状態なので、結果が正確なものなのかどうかデバック後のプログラムは詳細にチェックしなければいけないでしょう？

[PSRに準じたプログラム修正]
　以上のようなデバックをしながら、PSRにプログラムを準拠するようにプログラムを製造しています。デバックをしてプログラムを修正するのですから、そのタイミングで規約に揃えてしまうのは自然な流れといえます。ただ、PSRをそのまま利用しているのではなく、以下のような規約を作りプログラム修正をしています。

【ディレクトリ構成】
・システムを分割するフォルダは、3桁
・各業務システムを分割するフォルダは、4桁(2桁＋2桁)

【ファイルの基本構造】
・PHPタグ：ファイルは常に <?php または <?= のタグで始め、ショートタグ（<?）を使用してはいけません。
・文字エンコーディング：ファイルはUTF-8 without BOMを使用すること。

【クラス】
★Class機能概要
・1要素、1インスタンスで処理をする。
→処理対象の要素1つに対して、1インスタンスで操作する。

★クラス命名規約
・パスカルケースで記述する。
・クラス名の最後にClassとつける
・ファイル名と同一名とする。

★クラス記述規約
・クラスの開始ブレース（{）は、クラス名の次の行に配置します。
・クラスのプロパティとメソッド間には、1行の空行を挿入します。
・引数は1行ずつ記述し、70バイト目にその名称を記述する。

【コンストラクタ】
★コンストラクタ機能
・引数は必ず入力データチェックを行う。
・引数は、できるだけ型指定を行う。
・try～catchで記述し、エラーの場合は処理を終了する。
・引数として取得した値は、クラスの変数として設定する。
・Classの特性をよく理解し、取得した引数のプロパティ情報を取得し、クラス変数として管理する。

【メソッド】
★メソッド機能
・引数は必ず入力データチェックを行う。
・引数は、できるだけ型指定を行う。。
・正常時には目的の値を返却するが、異常の場合は、必ずfalseを値として返却する。
・異常時の詳細な情報は、クラス変数として管理し、必要に応じて内容を確認できるように製造する。
・異常時の場合は、処理の途中で中断できるが、正常な場合は、メソッドの最終行で値を返却する。
・返却値としてメソッド内で共通の変数を利用した場合、rtnとする。
・返却値の型指定を必ずします。

★メソッドの記述
・引数は1行ずつ記述し、70バイト目にその名称を記述する。
・メソッド内使用変数はメソッドの先頭にすべて記述する。
・変数名は、変数名のみを記述し、場合によって、初期化する。
・メソッドの開始ブレース（{）は、メソッド名の次の行に配置します。
・メソッドの引数リストが長い場合、複数行に分けることができます。この場合、各引数は新しい行に配置し、カンマで区切ります。

★メソッド命名規約
・キャメルケースで記述します。
・メソッド名の頭にmeをつける
┣publicメソッドの場合
┃　meの直後に、uをつける。
┗privateメソッドの場合
　　meの直後に、rをつける。

【プロパティ】
　キャメルケースで記述します。
★クラス変数機能
・クラス変数の設定は、setメソッドを製造する。
・クラス変数を取得する場合は、getメソッドを製造する。

★クラス変数命名規約
・private
　privateプロパティの頭にpriをつける
・public
　publicプロパティの頭にpubをつける

★プロパティ共通
・定数名：定数名はすべて大文字で、単語の区切りにアンダースコア（_）を使用します。
・メソッド内の処理結果を格納する変数は、何も制約がない場合ansにする。

【コメント】
・クラス、メソッドのヘッダには、以下の内容を記述する。
┣機能名
┣引数
┣返却値
┃┣正常時
┃┗異常時
┣製造者
┣製造年月日
┣更新年月日
┣リリース日
┣バージョン
┣概要
┗注意　←　必要に応じて
・コメントを1行で記述する場合は、同コメントは次行のプログラムを機能を説明するものでなければならない。
・コメントは、70バイト目から記述する
┣70バイト目から記述するコメントは、変数等の名称でなければならない。
┗90バイトを越える場合改行して記述する。
・コメントの内容とプログラムが矛盾がないように記述する。

【配列】
★配列の記述
・配列はショート配列構文 ([]) を使用します。
・配列が複数行にまたがる場合、各要素は新しい行に配置し、インデントします。

【例外処理】
★例外処理の記述
・try、catch 句の開始ブレースは、同じ行に配置します。
・catch 句は、前の try ブロックと同じインデントレベルで記述します。

【デストラクタ】
・クラス変数をすべて初期化する。

【共通記述方式】
・＝(イコール)の位置は、できるだけ、コンストラクタ内、メソッド内で先頭から同じ位置に記述する。
・if文で判定する場合、判定条件は1行ずつに記述し分かりやすく記述する。
・ファイルの終了行
┗ファイルの最後には必ず空行を1行入れる必要があります。
　*ファイルの最終行でコードが終わると、ファイルを他のツールで処理する際に予期しない問題を引き起こすことがあるためです。
・キーワードや制御構造のスタイル
┣キーワード（if、else、while、switch など）の後には、スペースを入れます。
┣制御構造の条件式の前後にはスペースを入れます。
┣開始ブレース（{）は同じ行に配置します。
┗switch 文の case と default は、インデントされませんが、その内部のコードはインデントされます。break ステートメントは case 内でインデントします。

【インデント】
・1インデント、4半角スペースとする。

【ファイル】
★インポート
　ファイルのインポートは、オートローダーで記述をする。

★名前空間と use ステートメント
┣namespace 宣言の後、1行の空行を入れる必要があります。
┣use ステートメントの後も 1行の空行を入れます。
┗同じ名前空間の複数のクラスをuse する場合は、個別に記述します。

以上の内容は、ChatGPTから教えてもらったPSRを基に作ったのですが、作ったものをChatGPTに評価したもらった方がいいことに気づきました。以下が、以上の規約のChatGPTの評価です。

■ChatGPTからの指摘
　全体的に非常に詳細に規定されていますが、いくつかの改善点や補足を提案します。
?ディレクトリ構成
改善点: PSR-4に準拠する場合、ディレクトリ構成についても、クラスの名前空間がディレクトリ構造と一致することを明示しておくと良いでしょう。
例: App\Controller\HomeController は app/Controller/HomeController.php に対応する。

?クラス
不足点: クラスの可視性についての記述がないため、public、private、protectedの適切な使用方法を追加するとよいです。
例: 「クラスは原則 public で宣言し、必要に応じて final または abstract を使用する」など。

?コンストラクタ
改善点: エラーハンドリングの詳細が少ないので、エラー時の処理方法（例外を投げる、ログに記録するなど）を規定するのも良いでしょう。

?メソッド
不足点: メソッドの可視性（public、private、protected）に関する規定を追加するとより詳細な設計となります。
例: 「メソッドの可視性は必要最低限とし、デフォルトでは private を使用し、外部からのアクセスが必要な場合にのみ public を使用する」

?プロパティ
改善点: プロパティの初期化についての規定を追加すると良いです。PSR的にはクラスのプロパティは定義時に初期化しておくことが推奨されます。
例: 「プロパティはクラス内で必ず初期化する。特にnullableなプロパティは初期値をnullに設定する」

?コメント
改善点: コメントの書き方は非常に詳細ですが、PSR-5（PHPDocスタイル）に準拠する形で規定しても良いでしょう。
例: PHPDocの形式で記述し、引数、返却値、例外を詳細に説明する。
php
コードをコピーする
/**
* This method sets the error message.
*
* @param string $errMsg Error message to set
* @return bool True on success, False on failure
*/

?配列
不足点: 配列の宣言時の可視性や型について、強く型付けする規定を設けると良いです。
例: 「配列にはできるだけ型を指定する。特に配列の型宣言はPHP 7.4以降の型指定を利用する」
php
private array $items = [];

?例外処理
不足点: 例外処理の仕組みに関して、finallyブロックの使用や、カスタム例外クラスをどう扱うかについて規定を追加できます。
例: 「例外が発生した場合、業務ロジックに応じて適切に例外処理を行い、必要に応じてfinallyブロックでリソース解放などの処理を行う」

?デストラクタ
不足点: クラス変数を初期化するだけでなく、リソース解放の必要がある場合などの記述があっても良いです。
例: 「デストラクタでは、クラス変数を初期化するだけでなく、リソース（DB接続やファイルハンドルなど）の解放を行う」

?ファイル
不足点: ファイルの命名規則や、どのファイルにどのクラスや関数を置くべきかを明示すると良いです。
例: 「クラス名とファイル名は一致させる。1つのファイルには1つのクラスのみを定義する」

?名前空間
不足点: 名前空間の命名規則（例えば、アプリケーションやモジュールごとの名前空間の付け方）を詳細に規定しても良いです。
例: 「アプリケーションの名前空間はプロジェクト名に基づき、ルートの名前空間に設定する」

　名前空間、ファイルインポート、ログ出力の部分の指摘は承知しています。実は、それを使うイメージができなかったことと、まだ当該規約に関連するプログラムを製造していなかったので、今まで規約に含めていませんでした。これ以降、プログラム製造時に考え、追記したいと思います。
　それ以外の項目については、規約に含めるかどうか検討します。後日結果について報告するかもしれません。

[あとがき]
　ChatGPTに聞いたところ、デバックできる文字数は、大体20,000～40,000文字以内で、有料だろうが、無料だろうがステップ数は変わらないそうです。変わるのは解析能力とか、レスポンスの早さになるそうです。解析能力の向上とは、今まで以上に品質のよいプログラムを製造できるということでしょうか？非常に興味があります。毎日利用させていただいているので、ビジネス開始してからは有料で利用させていただきたいです。
　このブログ更新後、プログラムのデバック及びPSRへのプログラム適用をします。

　では、また！！！

タグ：プロパティメソッドクラス JavaScript PSR ChatGPT 中小企業診断士

posted by ゼロから始めるシステム開発 at 16:42 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月09日

ssh_config最終検討　~ソフトウェア研究室~

　こんにちは！
　ナビゲータのEVEです。

　昨日まで、 ssh 接続時のセキュリティ向上案の内容を検討し、 AllowUsers まで終えました。本日は、 MaxAuthTries からです。

# パスワード認証を無効にする
PasswordAuthentication no

# 公開鍵認証を有効にする
PubkeyAuthentication yes

# チャレンジレスポンス認証を無効にする
ChallengeResponseAuthentication no

# PAMを有効にする（多要素認証などのため）
UsePAM yes

# ルートログインを無効にする
PermitRootLogin prohibit-password:

# 特定のユーザーのみログインを許可（必要に応じて）
AllowUsers user1

# 最大認証試行回数を制限
MaxAuthTries 5

# 詳細なログを有効化
LogLevel VERBOSE

# X11フォワーディングを無効化
X11Forwarding no

# SSHのポート番号を変更（デフォルトの22を避ける）
Port 2222 # 任意のポート番号に変更

[MaxAuthTries]
MaxAuthTries について、 ChatGPT に解説をしてもらいましょう！

　MaxAuthTriesは、SSH（Secure Shell）プロトコルにおいて、特定の接続に対する最大認証試行回数を設定するためのディレクティブです。この設定は、SSHサーバーのsshd_configファイルで管理されます。以下にMaxAuthTriesの機能とその重要性について詳しく解説します。

?認証試行回数の制限
　MaxAuthTriesは、SSHクライアントが接続中に認証を試みる回数の上限を指定します。例えば、MaxAuthTries 5と設定されている場合、クライアントは5回までの認証試行が許可されます。

?セキュリティの向上
　この設定により、ブルートフォース攻撃からの防御が強化されます。ブルートフォース攻撃とは、攻撃者がパスワードや鍵を総当たりで試みて不正アクセスを試みる手法です。MaxAuthTriesが設定されていると、一定回数内に正しい認証情報を入力できなければ、接続が切断されます。

?サーバー負荷の軽減
　認証試行回数を制限することで、不正な試行が続くことを防ぎ、サーバーへの負荷を軽減します。特に、多数のクライアントが同時に接続を試みている場合、無駄なリソース消費を抑えることができます。

?ユーザーの誤操作防止
　ユーザーが誤って間違ったパスワードや鍵を使用して何度もログインを試みることを防ぎ、無駄な試行を減少させます。これにより、ユーザー体験が向上します。

?ログインの監視と管理
　MaxAuthTriesの設定により、過剰な認証試行を行うユーザーを識別しやすくなり、セキュリティポリシーに従った管理が容易になります。特に異常な試行が検出された場合には、管理者が迅速に対応できるようになります。

■まとめ
　MaxAuthTriesは、SSHサーバーのセキュリティと効率性を向上させる重要な設定項目です。適切な値に設定することで、不正アクセスを防ぎつつ、サーバーの健全性を保つことができます。デフォルト値を理解し、必要に応じてカスタマイズすることが推奨されます。

　以上の通り、MaxAuthTriesは、パスワード認証などの場合、最大認証試行回数を指定します。 公開鍵認証方式 のため不要だと思ったのですが、公開鍵認証方式を採用した場合でも、 公開鍵 と パスフレーズ を用いるログイン方法があります。その場合、 ブルートフォース攻撃 などにより、無制限にログインを試行されるケースが考えられます。その攻撃により、システムに負荷がかかります。公開鍵がないとログインができないので、セキュリティ的にリスクはないと考えられますが、システム負荷という問題で試行回数を指定します。本番環境へ設定する場合は、この設定を有効にする目的から、1回でいいかもしれません。

[LogLevel]
　続きまして、 LogLevel について、解説をしてもらいましょう！

　LogLevelは、SSH（Secure Shell）サーバーの設定で使用されるディレクティブの一つで、ログの詳細度を指定します。この設定は、SSHサーバーが生成するログメッセージの量や重要性を制御します。LogLevelの機能について詳しく説明します。

?ログの詳細度の設定
　LogLevelは、SSHサーバーが記録するログメッセージのレベルを設定します。利用可能なレベルは以下の通りです：

・QUIET: ログメッセージを最小限に抑え、エラーや重要なメッセージのみを記録します。
・FATAL: 致命的なエラーのみを記録します。
・ERROR: エラーに関するメッセージのみを記録します。
・INFO: 一般的な情報メッセージを記録します。デフォルト設定です。
・VERBOSE: より詳細な情報メッセージを記録します。接続や認証の詳細などが含まれます。
・DEBUG: デバッグ情報を記録します。トラブルシューティングに役立ちますが、非常に詳細で大量のログが生成されます。
・DEBUG1, DEBUG2, DEBUG3: デバッグレベルをさらに詳細に制御できます。数字が大きいほど、詳細な情報が記録されます。

?セキュリティの向上
　より詳細なログを記録することで、不正アクセスや異常な動作を特定しやすくなります。例えば、VERBOSEやDEBUGレベルを設定すると、接続試行や認証の詳細が記録され、問題解決や監視に役立ちます。

?トラブルシューティングの支援
　DEBUGレベルのログを有効にすると、SSH接続の問題を診断するために必要な詳細な情報が得られます。これにより、接続が失敗する原因や設定ミスを特定しやすくなります。

?パフォーマンスへの影響
　LogLevelをDEBUGに設定すると、大量の情報がログに記録されるため、ログファイルのサイズが急増する可能性があります。また、ディスクI/Oの負荷が増加し、サーバーのパフォーマンスに影響を与えることがあります。そのため、通常はINFOまたはVERBOSE程度の設定が推奨されます。

■まとめ
　LogLevelは、SSHサーバーが生成するログの詳細度を制御する重要な設定です。セキュリティの強化やトラブルシューティングに役立つ一方で、設定によってはパフォーマンスに影響を与える可能性があるため、適切なレベルを選択することが重要です。通常は、必要に応じてINFOまたはVERBOSEが推奨されます。

本番環境は、高度なセキュリティでかつ高パフォーマンスを求めているので、LogLevelは、ChatGPTからの提案の通り、VERBOSEでいいでしょう！

[X11Forwarding]
　続きまして、 X11Forwarding について、解説をしてもらいましょう！

　X11Forwardingは、SSH（Secure Shell）プロトコルの設定項目の一つで、リモートサーバー上のGUIアプリケーションをローカルマシンで表示するために使用されます。この機能について詳しく解説します。

?X11とは
　X11は、Unix系オペレーティングシステムにおけるグラフィカルユーザーインターフェイス（GUI）を提供するためのプロトコルです。X11を使用することで、リモートサーバー上で実行されるアプリケーションのウィンドウを、ローカルマシンに転送し、表示することができます。

?X11Forwardingの機能
　X11Forwardingを有効にすると、SSHセッション中にリモートサーバーからローカルマシンへのX11アプリケーションの転送が可能になります。これにより、ユーザーはリモートのアプリケーションをローカルのデスクトップ環境で直接操作できます。

?セキュリティ
　SSHは、デフォルトでX11転送を安全に行うための暗号化を提供します。これにより、リモートアプリケーションの表示やユーザーの入力が暗号化され、セキュアな接続が確保されます。

?使用例
　X11Forwardingを有効にしたSSH接続を使用して、リモートサーバー上のアプリケーション（例えば、xtermやgeditなど）を実行すると、そのアプリケーションのウィンドウがローカルマシン上に表示され、ユーザーはリモートの環境にアクセスしているかのように操作できます。

サーバー側で普段 CUI で利用する場合であっても、この機能を利用することは可能です。但し、その場合、 xterm や gedit などの GUIツール がインストールされているということが前提となります。多分 XServer はインストールしていないと思われますが、自分が作った環境ではなく、不明な点が多いので、この記述を残し、かつnoと指定しましょう！

[Port ]
　次に Port について解説をしてもらいましょう！

　ssh_configファイルにおけるPortの設定について解説します。この設定は、SSHクライアントが接続する際のポート番号を指定するために使用されます。

■ssh_configのPort設定について
?基本概念
　**Port**は、SSHクライアントが接続するサーバーのポート番号を指定します。デフォルトではSSHはポート22を使用しますが、セキュリティや管理の理由から、異なるポート番号を設定することができます。

?利用シナリオ
1)セキュリティ向上
　サーバーのSSH接続ポートをデフォルトの22から変更することで、自動スクリプトやボットによる攻撃を減少させることができます。
2)複数のSSHサーバー管理
　同一のホスト名でも異なるサービスが異なるポートで動作している場合、ssh_configを利用して、それぞれのポート番号を明示的に指定することで簡単に接続できます。

?注意点
　サーバー側でポート番号を変更した場合、SSHクライアントの設定にも同じポート番号を指定する必要があります。また、ファイアウォールやセキュリティグループの設定も確認し、新しいポートが開放されていることを確認してください。

■まとめ
　ssh_configファイルのPort設定は、SSHクライアントが特定のポート番号でサーバーに接続するために重要な要素です。セキュリティ向上や複数のSSHサーバーの管理を容易にするために、適切に設定することが求められます。

sshのプログラムポートは、基本22です。デフォルトのままでは、入口を既に教えている状態にあり、攻撃を成功させないまでも、攻撃をさせる機会を与えることになります。そのため、ここでは、本来の22番以外の番号を指定する方がいいでしょう？例では、2222と非常に分かりやすい値をつけていますが、実際に設定する場合は、複雑な番号がいいでしょう！

[あとがき]
　以上で検討を終えます。検討の結果、当初考えていた設定内容で問題ないということになりました。
　明日からになりますが、適切な部分に記述できるように、サーバー調査を開始します。

　では、また！！！

タグ： ssh AllowUsers MaxAuthTries ChatGPT 公開鍵認証方式公開鍵パスフレーズブルートフォース攻撃 LogLevel X11Forwarding CUI xterm gedit GUIツール XSERVER Port

posted by ゼロから始めるシステム開発 at 15:38 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月08日

ssh_configの記述内容の検討　～ソフトウェア研究室

　こんにちは！
　ナビゲータのEVEです。

　昨日は、 ssh 接続時のセキュリティ向上案について、検討をしました。本日は、その続きで usePAM からになります。

[UsePAM]
　では、早速、UsePAMの機能について、 ChatGPT に聞いてみました。

　UsePAM は、SSH (Secure Shell) サーバーで PAM (Pluggable Authentication Modules) を利用するかどうかを制御する設定です。UsePAM が有効な場合、SSH サーバーは PAM を使って認証、セッション管理、アカウント管理、パスワード管理などを行います。

■UsePAMの機能
?PAM (Pluggable Authentication Modules):
・PAMとは
　PAM は、Linux や他の UNIX 系システムで汎用的に使用される認証モジュールのフレームワークです。様々な認証方式やセッション管理の処理を簡単にプラグインのように追加できる仕組みです。システム管理者は PAM を使って、ユーザーの認証やアクセス制御、セッションの設定などを柔軟に構成できます。

?認証管理:
　UsePAM を yes に設定すると、SSH サーバーは PAM を使ってユーザー認証を行います。これにより、パスワード認証、公開鍵認証、多要素認証 (MFA) など、様々な認証方式を PAM 経由で柔軟に統合できます。
　PAM を使うことで、認証に関する追加のセキュリティ機能（たとえば、ログイン試行回数制限、アカウントのロック機能、パスワード有効期限の管理など）が提供されます。

?セッション管理:
　PAM はセッション管理にも使用されます。ユーザーが SSH でログインした際に、UsePAM が有効だと PAM によって、ユーザーの環境設定やログイン時に必要な操作（たとえば、ホームディレクトリのマウント、ログの設定など）を行います。

?アカウント管理:
　PAM はアカウントの状態をチェックするためにも使われます。たとえば、アカウントが期限切れになっているか、パスワードが期限切れか、特定のユーザーにアクセス制限をかける必要があるかどうかを確認できます。これにより、ユーザーのアカウント状態に基づいたアクセス制御が可能になります。

?パスワード管理:
　PAM を使うと、システムのポリシーに従ったパスワード変更や強制的なパスワードリセットなどの管理が可能です。これにより、パスワードの強度や有効期限、再設定のルールを厳密に管理できます。

■UsePAM の有効化によるメリット
・柔軟な認証方法
　PAM を通じて、パスワード認証、公開鍵認証、多要素認証など複数の認証方式を簡単に設定できます。

・セキュリティの強化
　ログイン試行回数制限や、アカウントロック機能を PAM で設定することができます。また、PAM を使用して、LDAP や RADIUS など他の認証システムと統合することもできます。

・システム全体の一貫性
　SSH の認証だけでなく、システム全体で PAM による認証とセッション管理を統一することで、一貫したセキュリティポリシーを維持できます。

■PAMを無効化するデメリット
　PAMを無効にすると、これらの追加のセキュリティ機能や認証オプションを利用できなくなります。パスワードやアカウントの管理が制限され、単純な認証方式のみを使用することになります。

■まとめ
　UsePAM は SSH の認証とセッション管理に関して、柔軟かつ高度なセキュリティ機能を提供します。これにより、システム管理者は多様な認証方式をサポートし、ユーザーアカウントやパスワード管理を細かく制御できるようになります。PAM の機能を活用することで、SSH のセキュリティが強化されるため、サーバーの安全性を向上させる重要な設定と言えます。

usePAMの機能としては、以上の通りです。以上の内容と色々調べてみて、止めても大丈夫かなとも思う所はあったのですが、いろいろなソフト会社がusePAMを利用していろいろなソフトウェアを提供しているという記述があり、この機能を停止することにより、どんなことが起こるかが分からないという点を踏まえ、止めないほうがいいということで、ここは、yesを設定するという結論になりました。

[PermitRootLogin]
　次は、 PermitRootLogin についてです。

　PermitRootLogin は、SSH サーバーの設定で、リモートからの root ユーザーでのログインを許可するかどうかを制御するオプションです。PermitRootLogin の設定によって、root アカウントを利用した SSH 経由でのログインが可能かどうかを決定します。

■PermitRootLogin の機能
　PermitRootLogin オプションは以下の4つの値を指定できます。

?yes:
　root ユーザーでのリモートログインを許可します。これがデフォルトの設定の場合もありますが、セキュリティ上のリスクが大きい設定です。

?no:
　root ユーザーでのリモートログインを完全に無効化します。この設定により、root アカウントを使った直接ログインはできません。root 権限が必要な場合は、一般ユーザーとしてログインし、その後 su や sudo を使って root 権限を取得する必要があります。

?prohibit-password:
　パスワードを使用した root ログインを禁止し、公開鍵認証のみを許可します。この設定により、パスワードによる brute-force 攻撃を防ぎつつ、公開鍵認証を使って root でのログインを可能にします。

?forced-commands-only:　
　authorized_keys ファイルに制限付きのコマンドが設定されている場合のみ root ログインを許可します。これにより、root での SSH ログインは制限され、特定のタスク（バックアップやスクリプトの実行など）のみ実行可能にできます。

■セキュリティ上のリスク
★root のリモートログインを許可するリスク:
　root アカウントはシステム全体の管理権限を持つため、リモートから直接ログインできるようにすると、悪意のある攻撃者が root アカウントをターゲットにしてシステムに侵入するリスクが高まります。

・パスワード認証が有効であれば、ブルートフォース攻撃（総当たり攻撃）でパスワードが破られるリスクがあります。
・root アカウントが無効化されていない場合、すべてのシステムで root ユーザー名は同じであるため、攻撃者にとって狙いやすいターゲットになります。

★推奨される設定:
　セキュリティを強化するため、PermitRootLogin no を設定し、一般ユーザーでログイン後に必要に応じて sudo を使用して root 権限を取得するのが一般的です。

■まとめ
　PermitRootLogin の設定は、SSH サーバーにおいて root ユーザーのリモートログインを許可するかどうかを決定します。セキュリティ上の観点から、一般的には PermitRootLogin no として root の直接ログインを禁止し、一般ユーザーでログインした後に sudo などを使用して root 権限を取得することが推奨されています。

ここは、 root によるリモートログインを完全に排除したいので、noが適切だと考えます。現在 Ubuntu から提供されているインストールファイルは、rootによるログインはデフォルトで禁止されていますが、 XServer は、Ubuntuインストール直後からrootでログインすることが可能です。その点を考えると、XServerから提供されている環境では、 ssh_config にPermitRootLogin yesと記述されているはずなのですが、その記述がありません。他のファイルをインポートし実行しているのかと思ったのですが、その記述も有効になっていません。不思議です。今後、このセキュリティを実現しようとした場合、 ドツボにハマりそうな匂いぷんぷん です。

[AllowUsers]
　次は、 AllowUsers についてです。

　AllowUsers は、SSH サーバーでログインできるユーザーを指定するための設定オプションです。この設定を使用すると、特定のユーザーだけに SSH 接続を許可し、他のすべてのユーザーのアクセスをブロックすることができます。

■主な機能
?特定のユーザーのみログインを許可:
　AllowUsers にリストされたユーザーだけが SSH サーバーにログインできます。この設定を使うことで、不要なユーザーのログインを防ぎ、サーバーのセキュリティを強化します。

?複数ユーザーの指定:
　複数のユーザーを許可する場合、ユーザー名をスペースで区切って並べることができます。

?リモートホストの制限:
　ユーザーごとに、特定のホストからのみログインを許可することも可能です。ユーザー名の後に @ 記号でホスト名や IP アドレスを指定できます。

■AllowUsers を使う利点
・セキュリティ強化
　特定のユーザーだけにアクセスを許可することで、サーバーへの不正アクセスのリスクを減らします。

・アクセス制御の強化
　一部のユーザーだけに SSH ログインを許可し、他のユーザーを拒否することで、アクセス管理が厳格になります。

・ホストベースの制限
　特定のユーザーが特定のホストや IP アドレスからしかアクセスできないように制限できるため、セキュリティをさらに高めることができます。

■AllowUsers と DenyUsers
　AllowUsers の逆の設定として、DenyUsers というオプションもあります。これを使うと、特定のユーザーだけが SSH ログインを拒否され、その他のユーザーにはアクセスが許可されます。

■注意点
　AllowUsers が設定されている場合、リストにないユーザーはすべて SSH ログインを拒否されます。
　AllowUsers が空欄の場合、デフォルトですべてのユーザーにアクセスが許可されます（他の設定による制限がない場合）。
　この設定を使用して、サーバーのアクセスを厳格に制御し、セキュリティを高めることができます。

この設定は、 ホストベース認証 、 パスワード認証 、 公開鍵認証方式 すべて有効です。この設定は有効にすべきでしょう！

[あとがき]
　ChatGPTに最初に教えてもらった設定情報で問題になる点があるのではとも思いましたが、今のところないようです。usePAMのこともあるので、最後まで調べます。明日設定情報が決まると思いますので、それ以降毎日30分だけ、本件をどうやってサーバーへ設定するのか調べたいと思います。
　これに掛かりっ切るとすぐに数時間掛かってしまい、プログラム開発できなくなってしまうので・・・。まっ、実際に調査する前に、いろいろ調べるとは思いますが・・・。

　涼しくなったとはいえ、昼間の熱気が部屋にこもります。そのため夜はエアコンをつけて寝るのですが、寒くて寝ている途中で起きてしまうし、つけないと暑くて寝れません。ちょっと、中途半端な時期になりました。真夏の時よりはましなのですが、睡眠不足の日々が続いています。
　もう少しで涼しくなるようなので、何とか乗り切りたいと思います。

　では、また！！！

タグ： ssh usePAM ChatGPT PermitRootLogin root Ubuntu XSERVER ssh_config AllowUsers ホストベース認証パスワード認証公開鍵認証方式

posted by ゼロから始めるシステム開発 at 15:47 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月07日

www.pro2grammer.comのセキュリティを強化する　～ソフトウェア研究室～

　こんにちは！
　ナビゲータのEVEです。

　本日は、サーバーの設定をしようとしましたが、 XServer 側から私の問い合わせに対して、 root のパスワードを教えてほしいという分けの分からないメールが届きました。私の使用している環境は、他のユーザーとほぼ同じはずです。
　それよりも、デフォルトでrootログインできるなど特殊な設定をしているのは、XServer側です。rootのパスワードを知って、何をしようとしているのか分からないので、状況を説明し間接的に無理と伝え、最初お願いしたことへの返信をお願いしました。
　もしかしたら、自力で環境を解読しなければいけなくなるかもしれません。めんどくさ！ Ubuntu から提供されたインストールファイルをそのまま利用できれば、いいのだけれど・・・。無理か・・・。
　では、本日は、現在XServerに施そうとしているセキュリティの話をしたいと思います。
　以下が、/etc/ssh/ ssh_config に記述しようとしている内容です。

# パスワード認証を無効にする
PasswordAuthentication no

# 公開鍵認証を有効にする
PubkeyAuthentication yes

# チャレンジレスポンス認証を無効にする
ChallengeResponseAuthentication no

# PAMを有効にする（多要素認証などのため）
UsePAM yes

# ルートログインを無効にする
PermitRootLogin no

# 特定のユーザーのみログインを許可（必要に応じて）
AllowUsers user1

# 最大認証試行回数を制限
MaxAuthTries 5

# 詳細なログを有効化
LogLevel VERBOSE

# X11フォワーディングを無効化
X11Forwarding no

# SSHのポート番号を変更（デフォルトの22を避ける）
Port 2222 # 任意のポート番号に変更

ざっくりと以上で何をしようとしているかというと、セキュリティレベルの向上です。 公開鍵認証方式 を有効にし、公開鍵認証方式以外からのシステムへのログインを拒否しようとしています。加えて、 秘密鍵 の漏洩等を考慮して、デフォルトでrootからログインができる現状から、一般ユーザー(user1)のみログインできるようにしようとしています。これにより、秘密鍵がダッシュされた場合でも、サイトに甚大な損害の発生を防ぐことができます。
　それでは、その1つ1つでどのようなことをしようとしているのか確認をしたいと思います。

[PasswordAuthentication]
　まずは、 PasswordAuthentication から知らべてみましょう！まずは、 ChatGPT にどのような機能を有するのか聞いてみました。

　PasswordAuthentication は、SSHサーバーでパスワード認証を許可するかどうかを設定するオプションです。この設定によって、SSHクライアントがパスワードを使ってリモートサーバーにログインできるかどうかが決まります。

■PasswordAuthentication の機能と設定値
★PasswordAuthentication yes
・パスワードを使った認証を許可します。
・ユーザーは、リモートサーバーにログインする際に、パスワードを入力して認証を受けることができます。
・公開鍵認証と併用することもできますが、パスワード認証が有効であるため、パスワード攻撃（ブルートフォース攻撃）に対して弱くなる可能性があります。

★PasswordAuthentication no
・パスワードを使った認証を無効にします。
・これにより、パスワードを使ったSSHログインはできなくなり、代わりに公開鍵認証やその他の認証方式を使用する必要があります。
・公開鍵認証などのより安全な認証方式に切り替える場合に推奨される設定です。パスワード攻撃のリスクを軽減できます。

■注意点
　パスワード認証を無効にすると、公開鍵認証などの他の認証方法が正しく設定されていない場合、サーバーへのアクセスができなくなる可能性があるので注意が必要です。
　セキュリティ向上のために、公開鍵認証を設定した上で、PasswordAuthentication no を有効にするのが一般的です。

■結論
　PasswordAuthentication は、SSHログインでパスワードを使用するかどうかを決定する重要な設定項目です。セキュリティ強化のため、パスワード認証を無効にし、公開鍵認証などの安全な方法を使用することが推奨されます。

ここでの選択は、noでいいでしょう！

[PubkeyAuthentication]
　次は、 PubkeyAuthentication の機能について見ていきましょう！

　PubkeyAuthentication は、SSHサーバーで公開鍵認証を使用するかどうかを設定するオプションです。この設定によって、クライアントが公開鍵を使ってリモートサーバーにログインできるかどうかが決まります。

■公開鍵認証の概要
　公開鍵認証は、SSHクライアントとサーバー間で認証を行うための非常に安全な方法です。この認証方式は、非対称暗号化方式（公開鍵と秘密鍵）を使用します。
・クライアント側が秘密鍵（private key）を持ち、サーバー側が対応する公開鍵（public key）を持っている。
・クライアントがログインを試みると、サーバーは公開鍵に対応する暗号チャレンジを送り、クライアントは秘密鍵を使って応答します。
・サーバーはこの応答を検証し、正しい応答が確認できた場合にログインが許可されます。

■PubkeyAuthentication の設定値
★PubkeyAuthentication yes
・公開鍵認証を有効にします。SSHクライアントが公開鍵認証を使用してログインできるようになります。
・ユーザーは秘密鍵を使用して認証を行い、パスワードを使用する必要がなくなります（ただし、秘密鍵自体にパスフレーズを設定することはできます）。
・公開鍵認証は、パスワード認証に比べてセキュリティが高く、ブルートフォース攻撃やパスワード盗難のリスクを減らせます。

★PubkeyAuthentication no
・公開鍵認証を無効にします。クライアントは公開鍵を使ってログインできなくなり、パスワード認証など他の認証方式に頼る必要があります。
・公開鍵認証を使用しないシステムや特定のセキュリティポリシーに基づいて設定することができますが、一般的にはセキュリティを確保するために公開鍵認証を有効にしておくことが推奨されます。

■公開鍵認証の利点
?セキュリティが高い:
・パスワードを使わないため、パスワード漏洩のリスクやブルートフォース攻撃を防ぎます。
・公開鍵と秘密鍵はペアになっているため、秘密鍵が盗まれない限り第三者が不正にアクセスすることは困難です。
?利便性:
・公開鍵認証を設定すると、毎回パスワードを入力する必要がなくなり、利便性が向上します。
・鍵自体にパスフレーズを設定することで、さらにセキュリティを強化できます。

?自動化に適している:
　公開鍵認証は、スクリプトや自動化されたプロセスでのログインに適しており、パスワードを使わずに安全な接続を確立できます。

■注意点
　公開鍵認証を使用する場合、SSHクライアント側に秘密鍵、SSHサーバー側に公開鍵を適切に配置しておく必要があります。
・サーバー側では、ユーザーのホームディレクトリの .ssh/authorized_keys ファイルに公開鍵を保存します。
・クライアント側は、秘密鍵が安全に保管され、他人がアクセスできないようにすることが重要です。

■結論
　PubkeyAuthentication は、SSH接続における公開鍵認証を制御するオプションです。公開鍵認証は、パスワード認証よりも安全で、特にセキュリティを高めたい場合や自動化が必要なシステムでは推奨されます。

　公開鍵認証方式のみ有効にしたいので、ここは当然yesです。

[ChallengeResponseAuthentication]
　次は、 ChallengeResponseAuthentication の機能について見ていきましょう！

　ChallengeResponseAuthentication は、SSH（Secure Shell）における認証方法の一つで、クライアントとサーバー間での相互認証を行うために使用されます。この認証方式の特徴について以下に説明します。

■ChallengeResponseAuthentication の機能
?基本的な仕組み:
・サーバーはクライアントに「チャレンジ」と呼ばれるデータを送信します。クライアントはこのデータを受け取り、特定のアルゴリズムを使用して応答（レスポンス）を生成します。
・クライアントの応答は、サーバー側で事前に知っている情報（通常はパスワードやトークン）と照合され、正当なユーザーであるかを判断します。

?利用する場面:
・パスワード認証: クライアントがパスワードを入力する際、チャレンジレスポンス認証が使用されることがあります。ユーザーが正しいパスワードを入力すると、サーバーはそのパスワードを基に応答を検証します。
・多要素認証 (MFA): チャレンジレスポンス認証は、多要素認証を実現するために使用されることもあります。たとえば、ワンタイムパスワード（OTP）などを用いて、追加のセキュリティ層を提供します。

?PAMとの関連:
・UsePAMが有効な場合、チャレンジレスポンス認証はPAMを通じて多様な認証方式をサポートすることが可能です。これにより、パスワード以外の認証方法も組み合わせて使用できます。

?セキュリティの利点
・セキュリティ強化: パスワードが直接送信されず、チャレンジとレスポンスの形式で認証が行われるため、中間者攻撃（Man-in-the-Middle attack）に対する耐性が向上します。
・脆弱性の軽減: 認証情報が外部に漏れにくいため、フィッシングやブルートフォース攻撃に対してより安全です。

■まとめ
　ChallengeResponseAuthentication は、SSHの認証メカニズムとして、クライアントとサーバー間での安全な認証を実現するための手段です。パスワード認証や多要素認証と連携し、より高いセキュリティを提供するために利用されます。具体的には、ユーザーの認証情報を安全に扱うための方法として重要な役割を果たします。

セキュリティを強化する機能なのですが、このチャレンジレスポンスは、 パスワード認証 、 ワンタイムパスワード (OTP)、 多要素認証 (MFA)などに有効で、公開鍵認証には不要な機能なので、設定値はnoです。

[あとがき]
　ちょっと、長くなりましたので、本日はここまでとします。
　以前は、こんな資料のまとめ方をしていたことを思い出し、ちょっと、懐かしくなりました。初心に戻って、作業を進めます。

　では、また！！！

タグ： root Ubuntu ssh_config 公開鍵認証方式秘密鍵 PasswordAuthentication ChatGPT PubkeyAuthentication ChallengeResponseAuthentication パスワード認証ワンタイムパスワード多要素認証

posted by ゼロから始めるシステム開発 at 15:25 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月05日

反省会　～システム開発研究室～

　こんにちは！
　ナビゲータのEVEです。

　昨日ブログ更新後、 X (旧ツイッター)から以下のようなコメントを頂きました。

AIに頼る前にまずマニュアル読もうよ案件的な。
※XServerのLinuxディストリビューションってなんだろ。RHEL系だと「usePAM無効化するな」的な注釈もあったように思うんだけど

[angel (as ??の猫)　@angel_p_57のコメントより

ちょっと、焦りましたね・・・。ChatGPTを信用していましたから・・・。そのコメントを見た瞬間に、いろいろ調べたところ、ご指摘の通りだと言うことが判明しました。

[なぜこのようなことが起きたか？]
　このブログ、システムを開発に必要な項目を、それぞれ研究室として立ち上げています。開設当初は、研究室とつくにふさわしいレベルで調べていたのですが、今年の4月ぐらいからですかね？ 中小企業診断士 の勉強とか、起業とかがはいってきて、 ブログ に費やす時間が減りました。
　このブログを書く時間を90分に限定しているという話を何回かしていますが、それは、更新する時間です。その前の下調べの時間は含めていません。その時間を含めれば、以前は、数時間掛けていたかもしれません。ただ、近頃は、下調べを含めて、90分ぐらいになってしまったような気がします。今回の問題は、この点が一番大きいと思います。

[指摘事項内容の考察]
　指摘された内容は、「 usePAM無効化するな 」と言うことなのですが、usePAMとはどのような機能なのでしょうか？ ChatGPT 、 Gemini 、 Copilot すべてに聞いてみました。

　usePAM（Pluggable Authentication Module）は、LinuxやUnix系のシステムにおいて認証機能を管理するためのモジュールフレームワークです。usePAMとは、SSHサーバーや他のデーモンが認証にPAM（Pluggable Authentication Modules）を使用するかどうかを指定する設定項目です。具体的には、SSHサーバーの設定ファイル（通常は/etc/ssh/sshd_config）内でUsePAMというオプションを使用します。

?UsePAMの役割
1)認証の柔軟な管理
　PAMは、認証方法をモジュール化して柔軟に管理できる仕組みです。これにより、パスワード認証や二段階認証、バイオメトリクス認証など、さまざまな認証方式を簡単に追加・変更することが可能です。

2)セッション管理
　認証だけでなく、ユーザーセッションの管理やアカウントの制御、システムリソースへのアクセス管理も行います。

3)セキュリティポリシーの一元化
　複数のアプリケーションがPAMを使用することで、セキュリティポリシーを一元管理でき、同じ認証ポリシーを複数のサービスに適用することが可能です。

?UsePAMオプションの設定
/etc/ssh/sshd_configファイル内でUsePAMを設定することで、SSHデーモンがPAMを使用するかどうかを制御します。

・UsePAM yes: PAMを使用して認証とアカウント管理を行います。
・UsePAM no: PAMを使用せず、SSH独自の認証方法のみを使用します。

?PAMを使用した場合の利点
1)多要素認証のサポート
　PAMを使用すると、パスワード認証に加えて多要素認証（MFA）を簡単に設定できます。例えば、Google AuthenticatorやYubiKeyなどを組み合わせた認証が可能です。

2)アカウントロック機能
　アカウントのパスワードが一定回数以上間違えられた場合、自動的にロックする機能など、追加のセキュリティ機能を提供できます。

3)リソース制限
　PAMを使って、各ユーザーごとに使用できるシステムリソースを制限することができます（pam_limitsなど）。

4)ユーザーのアクセス制御
　PAMを使うと、ユーザーごとのログイン制御や特定の条件でのアクセス制御を設定することが可能です（例えば、pam_accessを使った特定IPアドレスからの制限など）。

■注意点
　UsePAMを有効にした場合でも、PasswordAuthenticationやChallengeResponseAuthenticationなど、SSH独自の認証設定と組み合わせて動作するため、他の設定オプションも適切に設定する必要があります。
　PAMの設定ファイルは通常、/etc/pam.d/ディレクトリにあり、各サービスごとの認証ポリシーを設定することができます。

こんな重要な機能を持ったモノだったのですね？ちょっと、冷や汗です。この記事を見たとき、背筋に冷たいものを感じました。angel (as ??の猫)さんには本当に感謝です。
　なお、usePAMを停止した場合のリスクについても、3AIに聞いてみました。

?セキュリティの低下
　PAMを無効にすると、セッション管理や認証の柔軟性が失われ、セキュリティが低下する可能性があります。例えば、パスワードの複雑さチェックや二要素認証などの機能が使えなくなります。

?認証の互換性の問題
　多くのサービスがPAMを前提としているため、これらのサービスが正常に動作しなくなる可能性があります。特に、SSHログインに影響が出ることが多いです。

?システム管理の複雑化
　PAMを無効にすると、各サービスごとに個別の認証設定を行う必要があり、管理が複雑になります。

?サードパーティアプリケーションとの互換性の問題
　多くのサードパーティアプリケーションは、PAM を利用してユーザー認証を行います。usePAM を無効化すると、これらのアプリケーションが正常に動作しなくなる可能性があります。

?認証方法の変更
　PAM を使用しない場合、認証は /etc/passwd や /etc/shadow ファイルに直接依存するようになります。これにより、パスワードのハッシュ化やその他のセキュリティ機能が制限される可能性があります。

[指摘事項の考察]
　angel (as ??の猫)さんからマニュアルを見た方がいいという指摘なのですが、検討した結果、難しいという結論になりました。私が最初Ubuntuを始めたとき読んだ本は、300頁強のなのですが、そこにはこの機能について記述はありませんでした。多分ですが、800、900頁ぐらいある本に書いてあると思います。ただ、購入しても、最後まで読み切ることができない、または、最後まで読んでも忘れていると思います。やはり、従来通りAIとの対話を通して作業を進めたほうがいいと思います。
　じゃ、今回の作業でどこがいけなかったのか考えてみましょう！以下に列記していました。

?知りもしない機能を勝手に止めてしまった。
?ChatGPTへの質問が公開鍵認証方式のみを有効にする方法を聞いており、セキュリティについては考慮していなかった。
?いつもなら、ChatGPT、Gemini、Copilotそれぞれに同じ質問をして確認をするのに、今回はしなかった。

他にもあるかもしれませんが、今パット思いつくのは以上の通りです。ようは、もっと時間をかけて深掘りをしなければいけないということです。
　なお、angel (as ??の猫)さんから、 RHEL 系の話がでていますが、 Ubuntu は、 Debian系 です。

[あとがき]
　今回は、OSの話でしたが、実は、気を抜くとこのようなことはしょっちゅう発生する可能性があります。なぜかと言えば、現在身をおいている業界は、今日生まれた技術は、明日古くなっているかもしれない業界だからです。
　Ubuntuを設定しながら、 PHP をプログラミングしながら、 MySQL を利用しながらそんなことを感じています。
　angel (as ??の猫)さんに今回指摘されたのは、タイミングとして良かったかもしれません。なぜかといえば、本番環境はこれからだからです。今後は、初心に戻って作業を進めたいと思います。
　本日は、 公開鍵認証方式 の設定方法について書く予定としていましたが、予定を変更し、反省会をさせていただきました。なお、usePAMを有効化したうえで、認証方式を、公開鍵認証方式にのみに限定する方法を昨日見つけました。まだ、設定はしていませんが、ChatGPT、Gemini、CopilotすべてのAIが問題ないといっているので、多分大丈夫でしょう？明日は、セキュリティの日なので、明後日に調査内容について報告させていただきます。もし、また、何かありましたらご指摘いただければありがたいです。

　では、また！！！

タグ：中小企業診断士ブログ起業 usePAM ChatGPT Gemini Copilot RHEL Ubuntu debian php MySQL 公開鍵認証方式

posted by ゼロから始めるシステム開発 at 16:02 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月04日

公開鍵認証方式　～ソフトウェア研究室～

　こんにちは！
　ナビゲータのEVEです。

　本日は、XServerへsshでログインする際の認証方式を、公開鍵認証方式にする作業をしました。

[よく考えたら]
XServer では、 公開鍵認証方式 を導入するのに、OSインストール画面で選択する仕様となっています。OSのインストール実行時に、 公開鍵 と 秘密鍵 を作り、そのうち秘密鍵を1度だけダウンロードするという仕様になっています。ただ、なんか、ここで違和感が・・・。Webサーバーとか作る場合、公開鍵と秘密鍵のペアをクライアント側で作成し、そのうち公開鍵を申請するという流れだった様な気がします。秘 密鍵って手元から手放しちゃいけないモノ だったのではないでしょうか？
　そんなことを考えながら、今回は、ノートパソコンの 仮想環境 で公開鍵と秘密鍵を作成し、公開鍵だけをアップロードして設定をしました。
　予め、公開鍵と秘密鍵を作っておいたと言うこともあるのですが、設定自体はすご～く簡単！公開鍵のリストと、クライアントの公開鍵の2ファイルをアップロードし、同ファイルに所有権とアクセス権を設定すれば、完了！
　後は、所定の方法で、クライアントから正常にアクセスできれば設定完了です。
　っでやってみたところ、 TeraTerm からも WinSCP からも正常に接続！！！

　ただ、この設定以降は、公開鍵認証方式のみでログインするようにしたいのですが、そこでつまづきました。

[公開鍵認証方式だけを有効にする]
　公開鍵認証方式のみを有効にするには、以下のファイルの設定を変更します。

/etc/ssh/ssh_config

以上のファイルを vi 等で表示後、以下の4行を追加します。

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

PasswordAuthenticationだけが、コメントアウトされた状態で、PasswordAuthentication noと記述されていましたが、それ以外の設定は、 ChatGPT から提供されたテキストをそのまま貼り付けました。
　ただ、ここで問題が・・・。このあと、 ssh のサービスを再起動すれば、設定が有効になるはずなのですが、有効になりません。どうしてなのかChatGPTに聞いてみたところ、ssh_configファイルの最終行に以上の4行を移動しろとの指示が・・・。移動後、sshのサービスを再起動してみましたが、うまくいかず・・・。ここから、またかなりの時間を使ってしまいました。

[じゃ、どうする？]
　かなりの時間を要しいろいろなことをしたのですが、ほとんど何をしたのか覚えていません。クライアントのキャッシュに何か残っているんじゃないかとか、いろいろ勘ぐっても分からず、最終的に、サーバーを再起動したら、設定が有効になりました。
　この設定は、ユーザー毎の設定ではなく、全てのユーザーに有効になります。したがって、これ以降は、 www.pro2grammer.com へは公開鍵認証方式でしかログインができません。これで、安心して作業ができそうです。

[あとがき]
　やはり、初めてやるコトって時間がかかってしまいますね・・・。ただ、現在は、ChatGPTがいるので、気軽に質問でき、以前よりは短時間で作業を完了することができます。イイ世の中になりました。
　では、明日は、具体的にどうするのか、最初から、公開鍵認証方式設定方法を御紹介したいと思います。

　では、また！！！

タグ：公開鍵認証方式公開鍵秘密鍵仮想環境 teraterm WinSCP VI ChatGPT ssh XSERVER

posted by ゼロから始めるシステム開発 at 17:20 | Comment(0) | TrackBack(0) | ソフトウェア研究室

2024年10月02日

LLPとは？　～システム開発研究室～

　こんにちは！
　ナビゲータのEVEです。

　本日は、昨日お約束したとおり、 LLP （ 有限責任事業組合 ）について書きましょう！
　実は、このLLPは、 中小企業診断士 試験の勉強中に学びました。中小企業診断士の 経営法務 では、いろいろな事業形態が紹介されており、その中にLLPがありました。そのため、本来なら「システムエンジニアが目指す中小企業診断士」で書く内容かもしれませんが、ITに関する起業ということで、こちらで書かせていただきます。

[LLP（有限責任事業組合）の最初の印象]
　最初LLPを見たとき目についたのは、 パススルー課税 ・・・。多くの事業形態は、法人税と所得税両方取られるのですが、実は、LLPは所得税のみが個人に課せられます。実は、 株式会社 での起業を検討している時には、二重に取られるという認識もなく、このパススルー課税を見たとき、ハットして、そのメリットを感じました。ただ、起業するなら、最初は、LLPかなとも思ったのですが、実は、LLPは設立後、株式会社へ変更できません。合名、合資、 合同会社 などは株式会社への変更は可能なのですが、LLPはそれを認められていません。そんな情報を横目に、LLPを作るのは面倒くさいし、個人事業主でいいかなと考えていたのですが、ビジネスプランのリスクのページで、保険等を考えているときに、個人事業主は、合名、合資会社の 無限責任社員 と同等の扱いだと知り、LLPのメリットを感じました。

[LLP（有限責任事業組合）の責任範囲]
　では、LLPの具体的な責任範囲は、どうなるのでしょうか？ ChatGPT に事故が発生した場合の、LLPの責任範囲について聞いてみました。

　LLP（有限責任事業組合）における事故やトラブルが発生した場合、組合員の責任範囲は以下のように定められています。

?有限責任
　LLPは「有限責任事業組合」という名前の通り、組合員は有限責任を負います。これは、組合が負った債務や損害について、組合員は出資額の範囲内でのみ責任を負うという意味です。つまり、事故等によりLLPが損害を受けたとしても、組合員の個人資産には基本的に影響が及びません。

?組合財産への責任
　LLPが契約や事故によって負う責任は、まず組合の財産をもって対応します。LLPは法人格を持たないため、組合自体が債務を負うという形にはなりませんが、組合の財産が損害賠償や負債に充てられます。

?組合契約書の規定
　LLPの組合契約書において、組合員間の責任分担や、組合員個々の業務遂行における責任について詳細に取り決めることができます。事故等が発生した場合、契約書に基づいて組合員間での責任の取り方が決まることが一般的です。

?故意または重大な過失の場合
　LLPの組合員が故意または重大な過失により事故を引き起こした場合、その組合員は出資額を超える賠償責任を負うことがあります。この場合、有限責任の枠を超えて、個人資産をもって責任を取らなければならない場合があります。

?外部との責任関係
　LLPは法人格がないため、外部との契約や法的責任は通常、組合名義で行われますが、個別の契約内容や法的な要件により、組合員が個人として責任を負う可能性もあります。特に外部との取引において、組合員個人に対する責任を明確にしない契約がある場合、慎重に対応する必要があります。

　このように、LLPの責任範囲は基本的に出資額に限定されますが、組合員の行為や契約内容によって変わる可能性もあるため、契約書や業務の進め方には注意が必要です。

以上の内容から分かりますが、LLPは 法人格 はありませんが、契約の主体となることができ、LLP名で契約した内容は有限責任となります。但し、個人名で契約した場合、または、重過失や故意で発生した事故等については、無限責任を負う可能性があります。

[あとがき]
　税金も所得税だけですし、LLP名での契約は、有限責任なので、LLPを作った上での起業は非常にメリットを感じました。そして、費用についても、最小金額で起業しようとしたら、1万円前後といった印象です。
　但し、不慮な事故が発生した場合など、ステークホルダ様に迷惑をできるだけかけたくなければ、保険等に加入するなどの措置が必要かもしれません。ただ、それは、大きく稼いでいる場合、大きな仕事をしていると考えられ、その責任も大きいと考えられますが、稼いでいないときはたいした仕事をしてないと考えられるので、保険等に入らないなどの判断ができるかもしれません。
　ちなみに、ChatGPTから聞いた話では、法人税も所得税も取られる株式会社で設立した場合、メリットになるのは、 900万円 以上の収入がある時だそうです。保険等を考える段階になった時、株式会社の検討もしたほうがいいかもしれません。

　では、また！！！

タグ：経営法務パススルー課税中小企業診断士法人格 LLP 有限責任事業組合株式会社合名会社合資会社 ChatGPT 無限責任社員合同会社

posted by ゼロから始めるシステム開発 at 17:48 | Comment(0) | TrackBack(0) | システム開発研究室

2024年10月01日

起業のリスクヘッジについて考える　～システム開発研究室～

　こんにちは！
　ナビゲータのEVEです。

　本日、 情報処理安全確保支援士 登録証が届きました。取得してから3年間、オンライン講習を3回、実務講習1回と真面目に受講した結果なのですが、現在コレクション状態です。全く有効活用できていません。
　そんな、2024年10月1日なのですが、 商工会議所 に行って作成したビジネスプランについて相談してきました。

[相談内容]
　相談した内容は、企業秘密と言うことで細かくは書けないのですが、以下のようなことを相談しています。

1)プログラム開発
2)セキュリティコンサルティング
3)SNS
4)システム開発

　当サイトの目標は、4)のシステム開発、ようはこのブログで紹介している EVE VProject で開発するシステムで需要のあるモノを開発をして起業しようとしています。それは、現在の開発状況を見て頂ければ分かりますが、すぐにできるモノではありません。そのため、1)2)3)の仕事を受託し、つなぎ、またはビジネス規模になったらそのタイミングで起業し、その力で4)を進めようとしています。それについて相談したのですが、目新しい情報はありませんでした。まっ、これも、日々の勉強のたまものっていうことでしょう！
　一言で言われた内容を表現すると、「まっ、がんばって！」って感じです(笑)。
　とりあえず、商工会議所では、 セキュリティコンサルティング のお客様を紹介までいかなくても、その手がかりでも手に入ればと思ったのですが、そんな情報さえありませんでした。
　2時間弱の会話から商工会議所ができることを引き出そうとしたのですが、事後的なコトが多かったような印象です。

[リスクヘッジ]
　以上なような状況で、かなり力を入れて臨んだのですが、肩すかしされたような状況でした。ただ、ビジネスプラン作成の過程で1つ思い出したことがありました。それは、 LLP （ 有限責任事業組合 ）です。
　個人事業主は、基本的にした行為について無限に責任を負います。ようは問題が発生した場合、その責任の範囲は限定されておらず、したことに対する責任を無制限においます。現在、多くの人が副業などの形で個人事業主として仕事をしていますが、その点は注意しなければなりません。
　私は、副業というわけではないのですが、個人事業主として活動しています。そのような状況で、EVE VProjectを成功したいばかりに、そんな重い責任を負うのは、現時点許容できません。
　法律だったと思いますが、とある文献を読んでいて、 合名、合資会社 についての解説を読んだことがありますが、その社員は、 無限責任社員 というのです。その時非常に驚きました。そんな企業形態は許容できないと・・・。
　ただ、もし、ここで私が起業した場合、個人事業主で、許容できないと感じていた、合名、合資会社の社員と同じ立場になるのです。
　そんなことを考えていたとき、思い出したのが、LLP（有限責任事業組合）でした。

[あとがき]
　ちょっと、長くなってしまったので、LLP（有限責任事業組合）については、明日また書きたいと思います。
　本日ブログで、リスクヘッジ、リスクヘッジと言って、自分がしたことに対して、自信がない、または無責任かのような発言をしていますが、そんなことはありません。自分の力で受注し、自分の仕事の名前で仕事をするわけですから、120%の能力を発揮して仕事に臨みたいのですが、その結果、常に100%満足した結果が得られるとは限りません。もしかしたら、セキュリティコンサルティングしたにもかかわらず、 ランサムウェア に感染したなんてコトもあるかもしれません。何万分の1の確率で発生する、そんな不慮な状況に備え対応したいと言っているのです。
　そんなことが発生した場合への対応策を明日書かせて頂きます。

　では、また！！！

タグ：商工会議所情報処理安全確保支援士 EVEVProject セキュリティコンサルティング LLP 合名合資会社無限責任社員ランサムウェア有限責任事業組合

posted by ゼロから始めるシステム開発 at 16:40 | Comment(0) | TrackBack(0) | システム開発研究室