IT人材が足りないとか、今後さらに不足すると言われている。ただそう言っているのが国だったりするのでいまいち信頼性に欠ける。あまりにマクロ的な見方によっているのではないかと思ってしまう。
クライアント企業(中小企業)を見ていて言えることは
何かを作れる(実装)という能力だけでなく、「必要なのか、良いのか悪いのか」を「判断」できる人材が中小こそ必要だと思う。
Web サーバーには、公開している特定のフォルダに対してアクセス制限をかける機能がある。レンタルサーバー各社では通常管理画面からこの機能を有効化することができる。
公式ヘルプ https://help.sakura.ad.jp/rs/2196/
公式ヘルプ https://www.xserver.ne.jp/manual/man_server_limit.php
上の各社いずれもアクセス制限の対象は「フォルダ」となっている。つまり各社管理画面の機能では、「ファイル」に対してアクセス制限をかけることはできない。ファイル単位の制限をしたい場合、.htaccess
ファイルを編集すれば実現は可能だがハードルが上がる。各社の管理画面上のアクセス制限機能が行っていることは、実際はこの .htaccess
ファイルを自動で編集するということ。従って手動で .htaccess
ファイルを編集する場合、自動で編集されている部分と競合しないように注意が必要。
上の各社ともに採用しているのは技術的には BASIC 認証と呼ばれる仕組み。古くから存在する単純なものであり、セキュリティの対策レベルとしては最低限の部類になるが、ないよりはマシ。応急的には十分使える。ただし SSL による暗号化が前提となる。
尚さくらのレンタルサーバーでは、この BASIC 認証の他に IP アドレスによる制限を組み合わせることができる。
Web サイトを公開すると、すぐに招かれざる客からの訪問を受けることになる。より正確には Web サーバーをインターネット上に公開した時点でそういった活動が始まる。これまでに観測した不正(ここでは「悪意」の意味)と言えるアクセスの傾向についてメモ。
いわゆる「パスワード総当たり攻撃」の一種と思われる、異常な回数のログイン試行を受けた際の対策と状況推移(WordPress のケース):
もし英単語や数字をつなげた程度のパスワードだと、いつか破られる可能性は十分ある。やはりパスワードは十分に複雑なものにして、覚えるのではなくブラウザに保存。ただしその端末のプライバシーのレベルに信頼がおけない場合はブラウザに記憶させるわけにはいかない。
ネット上では 「WordPress はセキュリティに問題がある」という論調の記事も多数見かけるが、その根拠として皆一様に挙げているものの1つが「管理画面がインターネット上に公開されている」というもの。ただこれは WordPress に限った話ではないので、ちょっと違うかなという気がする。大体どんなサービスにしても管理画面へのアクセス自体はインターネット上の「どこからでも・誰でも」できるのが普通だ。ただサービスによってセキュリティレベルが異なるのは、認証の複雑さ(多段階認証など)やサービス事業者側の監視体制のレベルの違いによるところが大きい。
あとは利用者側の意識の問題。特に最近はパスワード使いまわしのリスクは大きいと考えられる。先のパスワード総当たり攻撃でも、過去に流出したパスワードリストが使用される。
大変便利なのでメモ。
QUERY function :指定したデータ範囲(記述例:A2:E6
)の中で SQL を走らせて結果を配列として表示させることができる。
QUERY(data, query, [headers])
data には Google Sheet の「配列」を指定できる。これを使うと、複数のシートのデータを1つにまとめた上で SQL を走らせることも可能となり応用範囲が広がる。
例:=QUERY({'sheet1'!A1:C4;'sheet2'!A1:C4},"select Col2")
検索エンジンで上記タイトルのような文言を検索すると、いろいろな解説記事がたくさんヒットする。各サイトで言っていることをまとめる+各サイトの立場によるバイアスも考慮して情報を抽出してみる。(検索結果の上位20件程度を見た結果)
少しサーチしただけでもこれだけある。全てをいっぺんに実施するのは難しいし、挙げられている対策の中にはまずサーバーの仕様を確認したほうがよさそうなものも含まれている(後半のアクセス制限関連)。あるいは効果は大きいが運用面での影響が無視できないものもありそうだ。例えば IP アドレスの制限は強力だが、モバイルからの更新ができなくなる可能性が高い。そのあたりのトレードオフを考慮した結果が答えとなるため、サイトオーナーや組織ごとに対策の組み合わせは色々異なる。
既存の組み込み関数ではやりたいことができない場合、Google Apps Script (スクリプト)を書いてオリジナルの関数を作成することができる。
公式ガイド https://developers.google.com/apps-script/guides/sheets/functions
function
を定義(return
した値が関数を埋め込んだセルに入力される)という具合で特別な準備も要らずにオリジナル関数を作れるのでかなり便利。
例えば、Google スプレッドシートの LOOKUP 系関数(参考:関数リストhttps://support.google.com/docs/table/25273)は一番上からサーチして最初のヒットを返すが、それを一番下からさがしてほしい場合、案外良い方法がない。このようなケースでは、対応策はいろいろありうるが、その一つの解決策としてオリジナルの関数を作ってしまうということが可能。
レンタルサーバーを借りて、サイトをセットアップしたら(あるいはその前に)まずチェックしておきたい項目。
まず前提として、①当該サイトに何らかのアクセス制御の仕組みがあり、②それによって保護されている機密情報の類が現に存在するか、もしくは今後存在し得る、という場合に要検討。そうでない場合まで必ずしも厳密に考える必要はないと思う。
これは保護すべき情報が無かったとしても、導入が推奨される。しかし実施していないサイトも多い。最近はボタン一つで設定が可能な場合も多いので(主要レンタルサーバー)導入は簡単。
一方上述の前提条件に当てはまるような場合(保護すべきサイト)では必須。
レンタルサーバー各社で通常提供される機能ではある。ただ細かな設定方法やファイルの取得方法はいろいろ異なる。まず実施すべきは、ログファイルの保存期間のチェック。大抵、初期設定ではせいぜい1ヶ月間の保存期間などとなっている場合が多い。それでは短いので、できれば年単位に変更。
ログファイルの保存容量もサーバープランのストレージ全体容量に含まれるので、(ログファイルが容量を食いつぶさないように)初期値が短期間となっているのは致し方ないと思う。そこはあくまでユーザーの選択で期間を決めるべきところだ。
以上が最低限必要。WAF というのも最近当たり前に提供されるようになったが、過大な期待はできない。例えばサイトへの不正なログイン試行というような単純な攻撃さえ WAF のみでは止めることはできないと思われる。
Google スプレッドシートの IMPORTRANGE 関数は様々な「データ連携したい場面」で役立つ。何が便利なのか、特に従来のファイルサーバー型 Excel ファイル共有方式と比較してポイントを挙げると
「インポート元」のシートは「リアルタイムに」インポート先シートへとデータ転送される。インポートがうまくいくためには、以下の権限の設定が問題なければよくて、ファイルサーバーのようにネットワークに由来する様々な問題を考える必要がない。物理的にはインターネットに接続されていればよい。
というところが最大のポイントであり、有用性を生み出している部分だと思う。この柔軟な仕組みによって、情報の管理者は通常非開示の情報を他のユーザーに簡単に共有することが可能になる。つまり特定のケース、目的ごとに情報の共有を行える。
Google フォームの使いこなし・工夫についてメモ。時々悩むケースに、「質問の内容(文言)自体をユーザーの回答内容によって微妙に変えたりすることはできない」(はず)というのがある。
回答の選択肢によってジャンプ先の「セクション」を指定することはできる。ユーザーが既に回答済の質問(選択結果)によって、後の質問文を変えたいときは、基本セクションを使うことになる。
セクションだと都合が悪いのは、回答シート(スプレッドシート)で見たときに、質問ごとに別の列が使われるという点(仕様)。同じ列に全てのパターンについて回答が入ってほしい場合もあるが、その場合は後から回答シートを整形するしかなさそう。
次ページへ »« 前ページへ