「内部統制におけるアクセスコントロールの効率化 その３」 | オージス総研
WEBマガジン 「内部統制におけるアクセスコントロールの効率化 その３」 2013.11.11 株式会社オージス総研 栗田 健史 このシリーズは"内部統制におけるアクセスコントロールの効率化"をテーマとして初回及び第2回では、物理アクセスコントロールを網羅的に整理する方法、論理アクセスコントロールをアカウントのライフサイクルに沿って把握することで分かりやすいコントロールが実装できるということや、アプリケーションアカウントの全体像を例として、ID・パスワード設計、権限設計、ID・アクセス権の申請・登録についてお話をしました。 第3回では、その続きとして人がシステムを利用する段階の認証・認可について考えます。 さて、認証・認可って何なのでしょうか？何かよく似た言葉ですし、あまり普段使う言葉でも無いのでピンとこないですね。また、本文のテーマでもある"アクセスコントロール"にもよく似た言葉があり
(プログラマのための)いまさら聞けない標準規格の話 第2回 文字コード実践編 | オブジェクトの広場
プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第2回は文字コードの実践編です。 0. 前回の復習と今回の概要 システム開発で必要となる標準規格の話、前回 は文字コードの概要について説明しました。ざっくりまとめるとこんな内容でした。 「符号化文字集合」で文字集合と符号位置を定義し、「符号化方式」でバイト表現に変換していること。 日本では、しばらく文字集合 JIS X 0208 を、ISO-2022-JP、EUC-JP、Shift_JIS の符号化方式で利用してきたこと。 近年は、世界中の文字が扱える Unicode が主流となっており、UTF-8、UTF-16 などの符号化方式があること。 常用漢字、人名用漢字に限っても、字体を正確に扱おうとすると、JIS X 0208 の範囲では不十分であり、JIS X 0213、Unicode、サロゲートペ
(プログラマのための) いまさら聞けない標準規格の話 第1回 文字コード概要編 | オブジェクトの広場
プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第1回は文字コードの概要編です。 0. はじめに 業務システムを開発する場合、プログラミング言語、フレームワーク、ミドルウェア、業務知識など以外に、共通で必要となる知識があります。文字コード、国際化、日付・時刻の扱い、住所コード、郵便番号、電話番号などの各種コード、…。 本連載では、プログラマがシステム開発で必要となる、技術と業務の狭間の共通知識を解説して行きたいと思います。 連載第1回は文字コードの概要編です。コンピュータシステムにおいて、文字情報は文字コードを用いて処理されます。文字コードとは、各文字に対応付けられた数値 (符号) のことです。近年、新規に開発される業務システムでは Unicode が使われることが多いと思いますが、既存システムとの連携など他の文字コードが使用されることもまだま
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
アナリシスパターンを読もう｜オブジェクトの広場
アナリシスパターン。さまざまなところで「難解」、「難読」、「現場と無関係」とさまざまな憶測を呼んでいるようですね。でも、ツボにはまればわりと簡単に読めるし、非常に有用であることもわかってもらえると思っています。なにせ、私は、これなしで生きていけない体になってしまいました。まあ、肩の力を抜いてお話に付き合ってください。「なーんだ、簡単」と思っていただければ幸いです。 １．なにするものぞ まず、この先の話を読んでもらえるように、何の役に立つかから説明しましょう。アナリシスパターンの最大の御利益。まず、これを最大限に感じてもらうために、少し遠回りですが、要求獲得から設計初期に行われることについて少し触れます。 最初のかぎは、要求獲得にあります。要求獲得といえばユースケースですね。さて、ユースケースは、システムが達成すべき目標を「変化」の視点で表します。そこでは、「目的」として、現状のシステムを「
「宅ふぁいる便」サービスにおける不正アクセスについて ～お客さま情報の漏洩について（お詫びとご報告）～ | オージス総研
(*)ログイン用メールアドレスが無効で当社からの連絡が届かない件数（134万8，361件）含む （２）漏洩内容 氏名（ふりがな）、ログイン用メールアドレス、ログインパスワード、生年月日、性別、職業・業種・職種（*）、居住地の都道府県名、メールアドレス2、メールアドレス3。加えて、2005年から2012年の期間でのみ、お客さまに回答いただいていた必須入力情報でない、居住地の郵便番号、勤務先の都道府県名、勤務先の郵便番号、配偶者（*）、子供（*）も含まれます。 (*)該当する選択肢番号を選ぶ形式のため、具体的な職業・業種・職種、配偶者や子供の有無などは明記されていません。 ２．原因 （１）本サービスのセキュリティ対策に継続的に取り組んでいましたが、一部サーバーの脆弱性を攻撃され、不正アクセスが行われました。 ３．経緯 （１）サーバー内に不審なファイルが保存されていることを検知し、直ちに調査を開
（第２報）「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について（お詫びとお願い） | オージス総研
お知らせ （第２報）「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について（お詫びとお願い） 2019.01.26お知らせ ＞第１報についてはこちらをご確認ください ＞第３報についてはこちらをご確認ください ファイル転送サービス「宅ふぁいる便」におきまして、一部サーバーに対する不正アクセスにより、約480万件のお客さま情報のデータが外部に漏洩したことを確認いたしました。 ご利用の皆さまに多大なるご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。 なお、現時点で具体的な被害は確認されておりませんが、引き続き第三者を含めた調査を行っており、詳細が判明次第、改めてお知らせいたします。 １．漏洩したお客さま情報 （１）内容 「宅ふぁいる便」のお客さま情報 メールアドレス、ログインパスワード、生年月日、氏名、性別、業種・職種、居住地（都道府県のみ）（２）件数
【オブジェクト工房】第 1 弾 ライントレーサ・シミュレータ
1. はじめに 本連載はライントレーサをシミュレートするアプリケーションを作成する過程でどのような分析・設計・実装を行うか、実践を通じてまとめたものです。前編では、ライントレーサ・シミュレータ（*1）の分析を「どんなシミュレータを作成するか」という視点から説明しました。中編では、「どうやって目的を達成するか」という視点から設計について説明します。 本記事では、設計を行う際の入力として UML による分析モデルを用い、どのように設計モデルにマッピングさせていくかについて触れます。 対象となる読者としては、業務や研究などで設計・実装を行っている方を想定しています。 特に、分析工程での成果物を、設計工程の成果物に変換する際に何を手がかりにすればよいのか迷う方、日々の設計作業で設計判断の根拠に自信が持てない方を対象としています。また、実装者の方（設計を受け取って実装をする方）ですが、受け取った設計
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
